Subject: [Sipping] video fast update support

From: "Ashish Goyal" <[email-masked]>
Date: Thu, 4 Mar 2004 14:31:50 -0600

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

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 5 Mar 2004 14:17:16 -0500

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,

_______________________________________________
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: "Even, Roni" <[email-masked]>
Date: Fri, 5 Mar 2004 22:45:26 +0200

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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sun, 7 Mar 2004 16:32:08 +0100

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: Ashish Goyal [mailto:[email-masked]]
Sent: Thursday, March 04, 2004 3:32 PM
To: [email-masked]
Subject: [Sipping] video fast update support

Hi,

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.

---

From: "Eric Burger" <[email-masked]>
Date: Sun, 7 Mar 2004 20:51:57 -0500

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.  Moreover, it isn't signaling.

> 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] ' '
> 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
> 
> 
> 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.
> 
> 
>

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 9 Mar 2004 13:22:13 -0500

Cutting out the SIP Proxies and a TCP connection between the endpoints sounds very much like H.245.

That solution exists and works.

I was looking more for a SIP-oriented approach, which is how we ended up with RTCP (which, as you point out, already has the mechanisms in place).

> From: Pete Cordell [mailto:[email-masked]]
> Sent: Tuesday, March 09, 2004 12:19 PM
> To: Eric Burger; Ashish Goyal ; [email-masked]
> Subject: Re: [Sipping] video fast update support
> 
> 
> 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
> 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.
> 
> > 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
> > > >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
> > >
> > >
> > > >
> > > > >     I came across
> > > > draft-levin-mmusic-xml-media-control-03.txt - but I
> > > > > Sipping mailing list
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > Sipping mailing list
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > 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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 9 Mar 2004 22:45:55 +0100

Hi,

>That solution exists and works.

Maybe we should then look into that as a third option...

Also, just because you "cut proxies" it doesn't mean you have to remove all of them. If you eg would use a separate dialog for video control messages, and you really have a SIP network which is too slow for this signalling, you may not need all the proxies.

>I was looking more for a SIP-oriented approach, which is how 
>we ended up with RTCP (which, as you point out, already has 
>the mechanisms in place).

How does RTCP make it "SIP-oriented"? 

SIP has no bearer requiremtns, and doesn't even require the support of RTCP, so how would you solve this if you didn't have RTCP, or even RTP, on the bearer?

Regards,

Christer Holmberg
Ericsson Finland