Subject: RE: [Sipping] video fast update support

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 8 Mar 2004 09:09:41 +0100

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

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 9 Mar 2004 11:39:33 -0000

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

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