Subject: Re: [Sip] Open Issue #146: reuse of disabled media streams

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Dec 2001 14:08:23 -0500

There were no objections to the proposal at IETF 52.

Since there were no comments against, and one email comment in favor, I 
am marking this issue as closed. We will allow for reuse.

-Jonathan R.

Bert Culpepper wrote:

> I agree with the proposal to allow reuse.
> 
> Bert
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>>Jonathan Rosenberg
>>Sent: Wednesday, December 05, 2001 4:06 PM
>>To: [email-masked]'
>>Subject: [Sip] Open Issue #146: reuse of disabled media streams
>>
>>
>>Issue:
>>
>>Bis currently specifies that if a client disables a media 
>>stream (by setting
>>its port to zero), it cannot remove that stream from the SDP. 
>>As such, a UA
>>which constantly adds/removes media streams will cause the SDP to
>>continually grow, and never shrink. You definitely cannot 
>>remove them (since
>>the ordering is needed to match up streams between the 
>>offer/answer), but it
>>can work for a client to re-use a disabled stream. That is, 
>>when it wants to
>>add a new stream, it uses the "placeholder" held by the 
>>disabled stream. So,
>>instead of adding a new m line, the disabled m line is 
>>replaced with the m
>>line of the stream you want to add.
>>
>>This works because there is never any confusion about which streams
>>correspond to which. Think of the sequence of m lines in an 
>>SDP as a TDM
>>system, with each stream a "channel". Streams in the offer 
>>and answer are
>>correlated when they sit in the same channel. Once a stream 
>>is in a channel,
>>it can't move to another one, since then you lose 
>>correlation. When a stream
>>is disabled, its channel becomes empty. You can then insert a 
>>new stream
>>into that channel later on, and its clear that this is a new 
>>one (because it
>>replaces a disabled stream).
>>
>>So, the question is this: do we allow reuse of disabled 
>>streams in this
>>fashion?
>>
>>Points of discussion:
>>
>>Why do this at all? The only real reason is savings of 
>>bandwidth, since you
>>can reduce the size of the SDP. This is not a very common 
>>case for general
>>usage. However, the 3gpp guys are thinking about having the 
>>proxy disable
>>streams (egads!) based on some network policy about what 
>>codecs to use. They
>>don't want to be carrying around these zeroed out media 
>>streams. However,
>>our recommended approach with issues like this has been 
>>compression (ala the
>>signaling compression work in rohc). These streams will 
>>likely be compressed
>>very well, so the overhead may be moot.
>>
>>Gonzalo pointed out that an alternative is to use FID, since 
>>that could
>>provide a way to correlate the streams. In that case, you can remove
>>disabled streams altogether if they can be correlated. 
>>However, it wasn't
>>clear that FID actually allows for correlation of streams 
>>between offer and
>>answer. Rather, its meant for association of streams within 
>>the same SDP.
>>
>>Subsequent discussion on the list, in a long twisted and 
>>tedious thread
>>resulted in the conclusion that fid doesn't solve this problem.
>>
>>There was one comment advocating reuse if it doesn't break any
>>implementations, and another advocating it generally. I 
>>personally am on the
>>fence. We need to make a decision. So, I propose:
>>
>>Proposal:
>>---------
>>
>>Allow reuse.
>>
>>
>>Thanks,
>>Jonathan R.
>>---
>>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>>Chief Scientist                             First Floor
>>dynamicsoft                                 East Hanover, NJ 07936
>>[email-masked]                     FAX:   (973) 952-5050
>>http://www.jdrosen.net                      PHONE: (973) 952-5000
>>http://www.dynamicsoft.com
>> 
>>
>>_______________________________________________
>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use [email-masked] for questions on current sip
>>Use [email-masked] for new developments on the application of sip
>>
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

-- 
Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH: (973) 952-5000
http://www.dynamicsoft.com

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