Subject: [Sip] Open Issue #146: Re-use disabled streams

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 19:00:49 -0400

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.
More investigation was needed.

Proposal:

There was no concrete proposal yet. My leaning is to disallow reuse, and
stick with what we have.

Comments?

-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

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 23 Aug 2001 12:14:32 -0400

The idea of identifying m= streams using an explicit id rather than
position in the session description is very old. It seems much better
but is obviously backwards incompatible. Reusing disabled streams seems
more likely to be work with existing clients and so (still) appears to
be preferable.

Anders

---

From: Kim Liu <[email-masked]>
Date: Thu, 23 Aug 2001 13:40:11 -0400

[deleted]
> So, the question is this: do we allow reuse of disabled streams in this
[snipped] 
> There was no concrete proposal yet. My leaning is to disallow reuse, and

My inclination is to allow reuse, but I don't think it can
be done.  Particularly given the restriction on dynamic PT
reuse in issue #23.  Since the INVITE with SDP is used for
recovery, reusing/rewriting an old media stream slot in the
SDP might erase/hide information about the previous state
of the call (which dynamic PTs have been used, plus any
endpoint, media, or application specific information 
associated with the closed media stream) though I am unaware
of any application which is doing this today.  Unfortunately,
since the INVITE/200 + SDP is used for call recovery, 
that reuse will have to be avoided in order to maintain
a full history/state of the call in case recovery is
necessary.

Kim

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2001 09:59:27 +0300

Hi,

How about using the FID (or something similar) as a stream identifier,
identifying a stream for the whole session (not only within a specific
SDP)? Then it would be very easy to add/remove/change/whatever streams.

For example, assume a case where I set up a session with 5 streams.
Then, later in the session, I want to add one stream and remove one of
the old ones. By using identifiers one does not have to include any
information about the streams that are not affected by the mid-session
change.

Regards,

Christer Holmberg
Ericsson Finland