Subject: [SIP] Deleting Media Streams section in rfc2543bis

From: "Brett Tate" <[email-masked]>
Date: Thu, 6 Jul 2000 13:10:26 -0400

Appendix B.5 in rfc2543bis (July 1, 2000) mentions that 
a media stream is deleted by setting the port to 0.  It 
would be worth mentioning in this section that a media 
stream can also be deleted by the absence of a "m=..." 
line which was in the previous SDP for the call leg.

It might also be worth mentioning somewhere in 
Appendix B that receiving a completely new SDP within 
a call-leg should render the previous SDP obsolete.

If these comments are incorrect, please reply.

---

From: Igor Slepchin <[email-masked]>
Date: Thu, 06 Jul 2000 20:45:45 -0400

> Brett Tate wrote:
> It

This is wrong: it cannot. The m= lines are never removed, otherwise you
wouldn't be able to match m lines in response and request. Consider a
situation where the request contains

c=IN IP4 1.2.3.4
m=audio 54678 RTP/AVP 0 1 3
m=video 7346 RTP/AVP 10 13 (face)
m=video 7880 RTP/AVP 10 11 (presentation)
 
If the response contained something like 
m=audio 6540 RTP/AVP 0 1
m=video 6578 RTP/AVP 10 

there would be no way to tell which of the two offered media streams was
accepted and which one rejected.

> a call-leg should render the previous SDP obsolete.

See above. There is currently no way to completely replace SDP, you can
only update it either by rejecting some media sessions (by setting their
port # to 0) or by adding the new ones at the end of the list.

Thank you,
Igor Slepchin

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 7 Jul 2000 12:58:55 -0400

----- Original Message ----- 
From: Igor Slepchin <[email-masked]>
To: Brett Tate <[email-masked]>
Cc: SIPbell-labs <[email-masked]>
Sent: Thursday, July 06, 2000 8:45 PM
Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis

> accepted and which one rejected.

Thanks for the response.  

Let me clarify my comment/question a little more 
concerning section B.5.  After having went through 
the INVITE/200/ACK process to set up a call-leg, 
why does the re-INVITE need to keep passing 
around "m=" lines that are now considered to be 
just place holders?

The restriction of requiring the old "m=" lines to be 
passed in a re-INVITE, adds unnecessary 
restrictions on 3rd party call controllers (3pcc).

A---A's(3pcc)----B
           |
          C

For example, A and B are talking, and A has a 
3rd party call controller.  When a new call arrives 
at A's 3pcc from C, the 3pcc should be able to just 
perform a re-INVITE to allow A to communicate 
with C.  However because of the restriction, the 
3pcc would be forced to either insert the no longer 
used "m=" place holders into the SDP or use a 
transfer mechanism instead.

> port # to 0) or by adding the new ones at the end of the list.

See above comments and questions.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Jul 2000 13:06:34 -0400

> accepted and which one rejected.

While I don't disagree, practically speaking this
multiple-instance-of-one-type situation is fairly uncommon. We probably
still need to define what happens if you get a new SDP (it replaces the
old one). Realistically, we can't expect that

m=audio 4321 ...
m=video 5678 ...

will be answered by

m=audio 8888 ...
m=video 0

I suspect most implementations simply reply 

m=audio 8888

if they can't do video.

I think there was some discussion at some point of labeling streams in
SDP, which would simplify this.
(http://www.ietf.org/internet-drafts/draft-camarillo-sip-sdp-00.txt
seems to solve the opposite problem of "splitting" a single logical
stream across ports, but maybe the two concepts can be married.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Igor Slepchin <[email-masked]>
Date: Fri, 07 Jul 2000 14:13:03 -0400

The problem with replacing SDP is that the replacement is impossible to
detect generally. Say, I want to replace one media steam with another
one with the same set of codecs. There is no way to do this unless you
can match media lines in the new and old media descriptions. Mandating
the order is one way to do this and that's how it is supposed to be done
according to the RFC.

Generally, I see no harm caused by including "m=" lines with 0 ports. It
is probably OK to be forgiving about receiving SDP with missing media
lines if there is no ambiguity, but it is _not_ OK to generate such
SDPs. In the example Henning cited, what happens if the callee later
issues a re-INVITE with

m=audio 8888 ...
m=video 4444 ...

Did the callee accept the original media stream or offered a new one?
Besides, this clearly wouldn't work if all m= lines specified audio. So
why create special cases if everything is already handled by the generic
rules?

Using the stream labeling was proposed on this list before and it works
but gives no clear advantages I can think of. Besides, to be backwards
compatible (i.e., if one of the parties doesn't support the extension)
you have to be able to go back to the current algorithm so every
implementation would need to support both anyway.

BTW, note that draft-camarillo-sip-sdp-00.txt doesn't really solve the
problem it poses, namely splitting the same media stream across multiple
destination ports based on the codec type. SDP is the least of the
problems here. The real issue is that doing this split will break RTP:
real-time characteristics of RTP are almost lost since now there is now
way to detect (and recover from) packet loss, hence there is no good way
to adapt playout buffers; RTCP is broken so there is no way to
dynamically adapt to changing network conditions, and, finally, no
compliant RTP library will allow you change destination of the RTP
stream by changing the payload type of RTP packets. All of this was
discussed on the list, and the draft (somewhat surprisingly to me)
references that discussion.

Thank you,
Igor Slepchin

Henning Schulzrinne wrote:
> <...>
> Realistically, we can't expect that
> 
> m=audio 4321 ...
> m=video 5678 ...
> 
> will be answered by
> 
> m=audio 8888 ...
> m=video 0
>

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 7 Jul 2000 15:54:55 -0400

----- Original Message -----
From: Igor Slepchin <[email-masked]>
To: Henning Schulzrinne <[email-masked]>
Cc: Brett Tate <[email-masked]>; SIPbell-labs <[email-masked]>
Sent: Friday, July 07, 2000 2:13 PM
Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis

> the order is one way to do this and that's how it is supposed to be done

What's wrong with allowing a re-INVITE with a
new "o=" (or maybe the same "o=") to indicate
that all previous SDP
information is obsolete?  I think that this would
greatly increase the flexibility of 3rd party call
controllers.  It would also make it easier to attach
a SIP stack to end points which already generate
complete non-SIP specific SDPs.  It also
reduces the overhead of having to continually
store and pass around "m=" lines with 0 ports in
re-INVITEs.

> why create special cases if everything is already handled by the generic

I can see potential uses for adding the "m=" lines
with 0 ports within 200 responses or "Delayed Media"
ACKs; however I'm not sure the benefits outweigh the
restriction of forcing the use of a "SIP specific" SDP.

What are the benefits of using the "m=" with port 0 in
a re-INVITE?

---

From: Igor Slepchin <[email-masked]>
Date: Fri, 07 Jul 2000 16:27:09 -0400

Brett Tate wrote:
> information is obsolete?  

Several things:
1. This is not backwards compatible.
2. o= is a session level field so it doesn't let you remove individual
media streams. If we are to consider the new session id indicator in the
o= field as the sign that all media streams are being replaced, we would
have no way of modifying or removing some of the streams.

> I think that this would
> controllers.  

You are missing my point: it will not. Everything you want to achieve is
already possible within current spec. To change it in a not backwards
compatible way one needs better arguments than "we could do the same
thing some other way".

> It would also make it easier to attach
> complete non-SIP specific SDPs.  

Why? The SDP in SIP messages is 100% compliant with RFC2327.

> It also

What overhead? Bandwidth? We've been through this when we discussed
text-based vs. ASN.1. If you can't afford signaling overhead you
probably shouldn't even bother trying to set up the media session in the
first place.
 
> What are the benefits of using the "m=" with port 0 in

It's already in the spec and gives you all the flexibility you need.
It's a somewhat clumsy solution but it works and is implemented by quite
a few people by now.

Regards,
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Jul 2000 00:57:51 -0400

> 1. This is not backwards compatible.

This is pretty much a showstopper.

> compatible way one needs better arguments than "we could do the same

Let me emphasize Igors point. What you will want to do most of the time
in 3pcc is change the *address* that a particular media stream is sent
to. This does not require adding a new media stream. It simply requires
resending the SDP with that particular stream having a new address. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Jul 2000 08:46:51 -0400

I think a more interesting question is what to do if you do receive a
new SDP where a media line is "missing" (i.e., the SDP in the 200 has
fewer m= lines than the INVITE) or "misaligned" (e.g., the INVITE has
m=audio,m=video  while the 200 has m=video,m=audio). Given that many
simple implementations probably generate fixed SDP (audio only), this
situation is going to be common. I don't think implementations need to
do much: as long as I start applications based on the SDP that I receive
and use my own advertised ports to receive things will work fine for
common single-instance-of-media cases.

I suppose we should test whether anybody at the bake-off actually
handles port 0 or multiple audio (say) lines correctly. My recollection
is that it was difficult to impossible to find somebody that could test
a second media (video) with us, let alone two instances of a media type.

---

From: "Brett Tate" <[email-masked]>
Date: Sat, 8 Jul 2000 21:39:17 -0400

----- Original Message -----
From: Henning Schulzrinne <[email-masked]>
To: Igor Slepchin <[email-masked]>
Cc: Brett Tate <[email-masked]>; SIPbell-labs <[email-masked]>
Sent: Saturday, July 08, 2000 8:46 AM
Subject: Re: [SIP] Deleting Media Streams section in rfc2543bis

> situation is going to be common.

I completely agree.  The n-th position of a given SDP having
to match up with the n-th position of a corresponding SDP
forces a SIP stack to have to tweak an SDP received from
an upper layer or other protocol to make it SIP compliant.

I assume that someone will correct me if the position
alignment isn't SIP specific.  :)

> I don't think implementations need to

If possible, this is why I would like to see any short comings
with SIP's use of the SDP be addressed now instead of later.

Thanks for reading my comments/concerns.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Jul 2000 23:48:49 -0400

> alignment isn't SIP specific.  :)

I think its fair to say that it isn't.

Its a general problem associated with correlating multiple SDPs
associated with the same session. This can happen even in SAP. Lets say
a SAP announcement is sent, containing SDP 1 with two audio and a video
stream. Later on, an updated SDP (SDP 2) is sent out. This SDP has one
audio and one video stream. Now, if my media tools started off based on
SDP 1, and now SDP 2 comes, which audio stream should be removed? This
is the same problem we have in SIPs usage of SDP. Aligning media streams
between SDP allows us to determine this correlation.

> with SIP's use of the SDP be addressed now instead of later.

The alignment of media streams via positioning works just fine. Is it
elegant - no. But, it works, and its already there. If there is an
actual bug or unaddressed issue, then we can resolve it. But, I don't
want to change SDP usage in SIP just because its not elegant. We really
have to worry about backwards compatibility.

-Jonathan R.

---

From: Igor Slepchin <[email-masked]>
Date: Sun, 09 Jul 2000 00:36:32 -0400

Henning Schulzrinne wrote:
> My recollection

Siphone certainly does both. I vaguely remember actually testing this
feature with someone at the second bakeoff. In general, setting ports of
rejected media streams to 0 is rather trivial by any coding standards
and I can't see any reasons for not doing that (except people not being
aware that's necessary).

---
Igor Slepchin

---

From: Igor Slepchin <[email-masked]>
Date: Sun, 09 Jul 2000 16:49:12 -0400

Henning Schulzrinne wrote:
> m=audio,m=video  while the 200 has m=video,m=audio). 

I think it depends on how badly misaligned it is. Following generic "be
forgiving on what you receive and strict on what you send" principle, if
you can disambiguate the SDP in the response, it's safe to act as if all
the necessary m= lines where present. If you can't, you can either take
a guess or terminate the call - that should probably be a local
decision. But to keep our sanity I'd prohibit any mid-call media
renegotiation if one of the parties cannot generate proper SDP.

Thank you,
Igor Slepchin

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Jul 2000 15:20:46 -0400

> renegotiation if one of the parties cannot generate proper SDP.

If all else fails, a robust application can simply restart applications
if it gets a new SDP in an INVITE that doesn't line up with an earlier
SDP. This is needed in any event for the "other side crashed" case,
since the crashed entity may not know about old media streams. (It
should obviously still send a zero-port in the response for the media
entries it doesn't want.)

I suspect that this is how most (more sophisticated) implementations
will behave in any event on receiving an INVITE: look up existing media
streams (by type, address/port and position in description) and modify
local sending applications accordingly. If I get an INVITE with a new
``m='' line that doesn't correspond to any media stream, I need to start
a new one.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 09 Jul 2000 09:04:23 -0400

> between SDP allows us to determine this correlation.

No, that's not my understanding of SDP usage in SAP. In SAP, each o=
version is completely independent and has no relationship to the
previous one. In other words, logically, you end up tearing down all the
old media streams and listening/sending to new ones. A smart
implementation could keep a list of the old sessions and compare m=
lines for port and address, and keep those sessions/tools where nothing
has changed.

None of the first-generation Mbone tools (and I doubt many of the
current ones) have the ability to change port or multicast address
without restarting the tool, so starting afresh is pretty much the only
thing you can do in any event even for media property changes.

> have to worry about backwards compatibility.

Let me repeat this, since it seems to get confused: There are two wholly
separate issues:

Q1) What SDP should an implementation *send* if it wants to delete an
existing media stream or doesn't want to listen to a particular session
offered in an INVITE?

A: Same SDP, with port 0 for the media session not (no longer) wanted.

Q2) What should happen if somebody *receives* SDP that differs in order
or number of m= lines?

A: Two possibilities.

A1: Given that this makes simple implementations easier (don't have to
keep around all the irrelevant video, wb, chat, etc. lines) and simply
return a fixed SDP (m=audio something-or-other), it is probably a good
idea for the initiator to recognize this and set up the audio stream,
say, accordingly and not send data for the others nor start up the
respective tools. This doesn't work for multiple media streams of the
same kind, but works ok for the common case.

A2: Be a stickler and reject the SDP (and explain to customer why your
implementation won't accept phone calls...)

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 09 Jul 2000 08:48:52 -0400

> and I can't see any reasons for not doing that (except people not being
I'm not arguing against that, just for greater precision on the "liberal
what you accept side".