Subject: Re: [Sipping] video fast update support

From: "Pete Cordell" <[email-masked]>
Date: Tue, 9 Mar 2004 17:19:15 -0000

Since in the scenario it is the MCU deciding to do the switch, the time it
takes to decide to do a switch is common to both cases, so is irrelevant.
And by the time that this sort of signalling is taking place I would hope
that most of the SIP proxies will have dipped out.  Ideally there would be a
single direct TCP connection.  Besides, there's no requirement for a signal
to follow the SIP route at all.

The two ways seems to be:

1)
- MCU app -> Client App: Do fast update
- Client app -> MCU App: OK
- Client App -> Client video encoder: Do fast Update

2)
- MCU app -> MCU video decoder: Request fast update
- MCU video decoder -> client video encoder: RTCP fast update request
- Client video encoder -> MCU video decoder: a fast update frame
   (effectively acknowledges the request)
(This assumes that the MCU video decoder takes responsibility for ensuring
that the fast update actually arrives by retransmitting the request if
required.)

On that basis there's not a lot to choose between them, which probably
explains why the debate went on so long before!  Since there is an RTCP fast
update request primitive, and there isn't currently a standard application
level primitive, that would tend to make the RTCP method more attractive.
Whether this will change when we get more into conference control I'm not
sure.  For example, things like "Your video is now the conference video
source", "You are now seeing X".  The different paths for the things that
would ideally be synchronised seems worrying.  Still, we can cross that
bridge when we come to it.

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
http://www.tech-know-ware.com
http://www.xml2cpp.com
+44 1473 635863
=============================================

----- Original Message -----
From: "Eric Burger" <[email-masked]>
To: "Pete Cordell" <[email-masked]>; "Ashish Goyal "
<[email-masked]>; <[email-masked]>
Sent: 09 March 2004 15:36
Subject: RE: [Sipping] video fast update support

Actually, we do it for the latter: How to do the freeze frame / Send me a
full frame for MCU situations.

However, (and this was debated ad nauseum on the mmusic and SIP lists) this
is purely a media signaling, not application signaling, problem.  That, plus
the reality of how long it takes for (1) the MCU to decide to switch and (2)
how long it takes SIP signaling to traverse proxy networks, the "SIP way"
isn't really workable.

> -----Original Message-----
> From: Pete Cordell [mailto:[email-masked]]
> Sent: Tuesday, March 09, 2004 6:40 AM
> To: Christer Holmberg (JO/LMF); Eric Burger; 'Ashish Goyal ';
> [email-masked]
> Subject: Re: [Sipping] video fast update support
>
>
> Does the method you use for video fast update not depend on
> the reason you
> are doing it?
>
> For example, if you are doing a fast update to recover from
> errors (missing
> blocks etc), then RTCP seems the right place.  Reliability is
> not a major
> problem because the decoder that requested the update will be
> able to see
> whether a refresh actually occurred.  (My recollection is
> that H.323 SHOULD
> support this!)
>
> If you are doing a fast update as a result of an MCU switch
> (something like:
> tell receivers to freeze display, switch 'routing' inside
> MCU, tell sender
> to send fast update - typically unfreezing decoder) then an
> application
> level signal seems the right way to go.  Here reliability of
> delivery is
> more important because its the application that needs to know that the
> update was (will be) successful, and typically the decoder
> will not bother
> it with such information.
>
> Pete.
> --
> =============================================
> Pete Cordell
> Tech-Know-Ware
> [email-masked]
> http://www.tech-know-ware.com
> http://www.xml2cpp.com
> +44 1473 635863
> =============================================
>
> ----- Original Message -----
> From: "Christer Holmberg (JO/LMF)" <[email-masked]>
> To: "'Eric Burger'" <[email-masked]>; "'Ashish Goyal '"
> <[email-masked]>; <[email-masked]>
> Sent: 08 March 2004 08:09
> Subject: RE: [Sipping] video fast update support
>
>
> >
> > Hi,
> >
> > >So it is OK to have refresh latencies on the order of a few
> > >seconds?  Remember, any signaling solution goes through all
> > >of the record-route proxies.
> >
> > Not necessarily. That depends on how you implement it, if
> the refresh
> messages are sent within the same dialog as the other SIP
> messages (compare
> to the kpml discussion) etc.
> >
> > >Moreover, it isn't signaling.
> >
> > Well, whatever you want to call it, but it's done on the
> signalling plane,
> isn't it? :)
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> > >
> > > > -----Original Message-----
> > > > From: Christer Holmberg (JO/LMF)
> > > > [mailto:[email-masked]]
> > > > Sent: Sunday, March 07, 2004 10:32 AM
> > > > To: 'Even, Roni '; [email-masked] '; Eric
> Burger; ''Ashish
> > > > Goyal ' '; [email-masked] ' '
> > > > Subject: RE: [Sipping] video fast update support
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I would prefear a "signalling level solution", instead of the
> > > > RTCP solution. Like Roni said, H.323 (or any system using
> > > > H.245) would not support the RTCP solution, so it would eg
> > > > complicate interworking scenarios, and also in general making
> > > > nodes supporting multiple protocols more complicated.
> > > >
> > > > I've had off-line discussions with Roni about the xml
> > > > solution, and I do have some issues on it, but I still think
> > > > that a signalling level solution is the right way to go.
> > > >
> > > > Regards,
> > > >
> > > > Christer Holmberg
> > > > Ericsson Finland
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > To: 'Eric Burger '; 'Ashish Goyal '; [email-masked] '
> > > > Sent: 5.3.2004 21:45
> > > > Subject: RE: [Sipping] video fast update support
> > > >
> > > >  Asish,
> > > > This is a big discussion, I assume that you ask about
> fast update as
> > > > well as
> > > > freeze request. The RTCP solution is not a fast update
> request as we
> > > > know it
> > > > from video conferencing systems, it is an indication from
> > > the receiver
> > > > and
> > > > it leaves open to the encoder to decide what it wants to do.
> > > > The levin draft is being used by some vendors and as
> far as I know
> > > > others
> > > > will follow. I am not aware of RTCP feedback being used for
> > > signalling
> > > > application level fast upadte request. You should be aware
> > > > that the RTCP
> > > > feedback will cause interop problem between H.323 and
> SIP since a
> > > > signalling
> > > > GW will not be able to convey it.
> > > > Regards
> > > > Roni Even
> > > > -----Original Message-----
> > > > From: Eric Burger
> > > > To: Ashish Goyal; [email-masked]
> > > > Sent: 05/03/2004 21:17
> > > > Subject: RE: [Sipping] video fast update support
> > > >
> > > > The reason you don't see stuff on FFR on the SIP list is
> > > > because it is a
> > > > RTCP, not SIP, issue.  Many folks are signaling the update
> > > request in
> > > > RTCP.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Ashish Goyal [mailto:[email-masked]]
> > > > Sent: Thursday, March 04, 2004 3:32 PM
> > > > To: [email-masked]
> > > > Subject: [Sipping] video fast update support
> > > >
> > > >
> > > > Hi,
> > > >     Is there a defacto standard which is being used by sip video
> > > > endpoints. ?
> > > >     I came across
> > > draft-levin-mmusic-xml-media-control-03.txt - but I
> > > > would like to know if thats the way the video vendors are going.
> > > > Thanks,
> > > > Ashish
> > > >
> > > >
> > > > _______________________________________________
> > > > Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use [email-masked] for questions on
> current sip
> > > > Use [email-masked] for new developments of core SIP
> > > >
> > > > _______________________________________________
> > > > Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use [email-masked] for questions on
> current sip
> > > > Use [email-masked] for new developments of core SIP
> > > >
> > > > This communication is confidential and intended solely for
> > > > the addressee(s). Any unauthorized review, use, disclosure or
> > > > distribution is prohibited. If you believe this message has
> > > > been sent to you in error, please notify the sender by
> > > > replying to this transmission and delete the message without
> > > > disclosing it. Thank you.
> > > >
> > > > E-mail including attachments is susceptible to data
> > > > corruption, interruption, unauthorized amendment, tampering
> > > > and viruses, and we only send and receive e-mails on the
> > > > basis that we are not liable for any such corruption,
> > > > interception, amendment, tampering or viruses or any
> > > > consequences thereof.
> > > >
> > > >
> > > >
> > >
> >
> > This communication is confidential and intended solely for the
> addressee(s). Any unauthorized review, use, disclosure or
> distribution is
> prohibited. If you believe this message has been sent to you in error,
> please notify the sender by replying to this transmission and
> delete the
> message without disclosing it. Thank you.
> >
> > E-mail including attachments is susceptible to data corruption,
> interruption, unauthorized amendment, tampering and viruses,
> and we only
> send and receive e-mails on the basis that we are not liable
> for any such
> corruption, interception, amendment, tampering or viruses or any
> consequences thereof.
> >
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
>
>
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 9 Mar 2004 10:36:21 -0500

Actually, we do it for the latter: How to do the freeze frame / Send me a full frame for MCU situations.

However, (and this was debated ad nauseum on the mmusic and SIP lists) this is purely a media signaling, not application signaling, problem.  That, plus the reality of how long it takes for (1) the MCU to decide to switch and (2) how long it takes SIP signaling to traverse proxy networks, the "SIP way" isn't really workable.