Subject: Mapping media streams

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 07 Mar 2000 13:39:38 +0200

Hi,

User A wants to establish a session with user B. A's SDP includes two
video streams.

m=video 1000 RTP/AVP 31
m=video 1002 RTP/AVP 31

User B wants to have just one video stream, so B sends back an SDP with
just one video description:

m=video 5000 RTP/AVP 31

How does A know which of its two video streams B wants to receive?

Should in these situations (multiple streams containing media of the
same type) the "i" attribute of SDP be used? (or it is not intended for
this?)

m=video 1000 RTP/AVP 31
i= front camera
m=video 1002 RTP/AVP 31
i= panoramic camera

This way B can choose wich one he wants to receive:

m=video 5000 RTP/AVP 31
i= front camera

This example may look pretty stupid, but when QoS preconditions are
added to the SDP there are some useful scenarios for this.

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 07 Mar 2000 12:17:13 +0000

> How does A know which of its two video streams B wants to receive?

This is all described in appendix B of rfc 2543.

   The caller and callee align their media descriptions so that the nth
   media stream ("m=" line) in the caller's session description
   corresponds to the nth media stream in the callee's description.

SDP bodies in 2xx responses to INVITEs must have the same number of m=
lines as did the request, and in the same order, i.e. the n'th m= line
of the response corresponds to the n'th line in the request.  If the
caller can't or doesn't want to establish a particular stream it must
still have the m= line in the response:

   If caller and callee have no media formats in common for a particular
   stream, the callee MUST return a session description containing the
   particular "m=" line, but with the port number set to zero, and no
   payload types listed.

In your example the callee might return

  m=video 5000 RTP/AVP 31
  m=video 0 RTP/AVP

Frankly, this method of referring to media streams isn't the most
wonderful aspect of SIP.  Once upon a time there was a thread on a
specific issue relating to SDP media alignment:

  http://www-uk.hpl.hp.com/people/ak/confctrl/1999/msg00297.html

> same type) the "i" attribute of SDP be used? (or it is not intended for

Something along these lines was actually proposed by Peter Peldan.  The
idea was to associate a UID with media streams and then use that to
refer to them later, e.g. in the response to the initial INVITE and
later, when renegotiating streams using re-INVITEs.

IMHO this would be a big improvement on the present method of referring
to streams by position in the initial INVITE.  

> added to the SDP there are some useful scenarios for this.

Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 07 Mar 2000 16:18:51 +0200

Hej Anders,

Thanks for pointing out the URL with the previous discussion (I have
included a mail from Peter Peldan below). What was the final result of
the discussion?

Since I have seen no changes to the spec I guess the media alignment is
still done matching the nths "m" lines, right?

What about if the callee wants to add a media stream to the session?
The callee might want to send a new m line in the 200 OK. Should this be
allowed?

Comments?

Thanks,

Gonzalo

> > added to the SDP there are some useful scenarios for this.

************************************
Igor Slepchin said
>I think I misunderstood your intentions.

No Igor, you were more correct the first time but anyhow: I believe the
confusion seems to grow on both sides and it may be time to summarize
what we know:

1. Current suggestion in SIP is that we should/must line up all media
descriptors meaning that we cannot have one media-descriptor mapped to
two on the other side, or that we cannot allow one media-session being
described by two media-descriptors. If there are two media-descriptors
in the callers SDP, the caller wants two sessions and the callee should
accept both or send an error.

2. Ellemtel and HP-Labs plug-in architecture makes it desirable to allow
two media-descriptor for the same media-session. We wish to be able to
use two -- or more -- media descriptors for the same session. The callee
could accept the call by only supporting one of them.

What solutions do we see?

Solution 1. 
We allow multiple media descriptors for one session and label every
media-session with the i= field. There's no need to line up media
descriptors.
Advantage: Very flexible solution for using plug-ins. We do not tie up
the SDP to a too strict specification that may prevent future -- yet
unknown -- reasons for splitting session.
Disadvatage: We get backward compatibility problems. The callee's UAS
may not understand that the two media-descriptors belongs to the same
session, and may open two streams. We may get synchronization problems
when RTP-streams are switched between ports/modules.

Solution 2.
We keep the media-descriptor line-up requirement and make no changes.
Advantage: No changes to the current spec. We do not risk the kind of
synchronization problems described earlier.
Disadvatage: We tie up the SDP so strict that it may cause problems for
future session types that prefer to be splitted into multiple media
descriptors for whatever reason. It may cause an unflexible plug-in
architecture (which may be avoided to some extent by using the solution
below)

I believe solution 2 might be the best solution due to the problems of
backwards compatibility only. I am not happy about causing such an
inflexible SDP specification for SIP. Hopefully future session types can
all be fit into one media descriptor? 
The problem with using multiple e.g audio-plug-ins may perhaps be solved
by, in the UAC, automatically make another call with the other plug-in
if the first fails due to non-acceptabel media descriptor? The user will
in that case only notice a slight delay. For the callee there's no
problem since his UAS may choose what plug-in to use based on the
caller's SDP. We will only lose the possibility of switching between
plug-ins during the call, which perhaps noone really wants anyway?

Peter Peldan

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 07 Mar 2000 14:45:19 +0000

> included a mail from Peter Peldan below). What was the final result of

Peter and myself got tired of arguing first, so the spec didn't change
;-). More seriously, this was after SIP had made it to proposed
standard, making it somewhat tricky to radically modify it. Also it
isn't *that* big a deal - OK so UAs may not be able to freely use codecs
from different RTP libraries within the same leg, but that's hardly the
end of the world.

I still think using explicit (and opaque) identifiers for media streams
in SDP (or whatever session description language is used) is preferable
as it's cleaner and simpler and probably less error prone than
rearranging and matching SDP m= lines.

> still done matching the nths "m" lines, right?

Right.

> The callee might want to send a new m line in the 200 OK. Should this be

I don't think anything in rfc 2543 disallows it, but I wouldn't have
thought many UAs would handle it the way you'd want it to. Ours
certainly wouldn't.  The callee could accept the call and then try a
re-INVITE, though.

Anders

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Mar 2000 11:50:40 -0500

> rearranging and matching SDP m= lines.

No doubt. The problem is backwards compatibility...

> certainly wouldn't.  The callee could accept the call and then try a

The spec doesn't detail adding and removing of media streams. The basic
mechanism is there, though:

1. to add a stream, add an additional m line at the bottom in a
re-INVITE. 
2. to remove a stream, set its port to zero in a re-INVITE

(2) is consistent with how a UAS rejects a stream offered by a UAC. We
should be sure to add these to the next revision.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com