Subject: RE: [SIP] Multiple sessions in SDP payload

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 18 Jul 2000 11:49:38 -0400

I strongly second this view, which we have incorporated into the Megaco
media negotiation rules in the belief that the call signalling protocol
would behave the same way.

> -----Original Message-----
> From:	Philip Levis [SMTP:[email-masked]]
> Sent:	Tuesday, July 18, 2000 11:28 AM
> To:	[email-masked]
> Subject:	Re: [SIP] Multiple sessions in SDP payload
> 
> On Tue, 18 Jul 2000, Jonathan Rosenberg wrote:
> 
> > As for multiple sessions per SDP, I don't know what the value of this
> > would be. rfc2543 is silent on this, and I would suggest it be
> > disallowed within SIP.
> 
> There is a simple value; it provides additional information at little
> cost.
> 
> In short, it allows for an explicit distinction to be made between
> multiple streams, and multiple options for a stream. There's a very
> pronounced (and useful) difference between:
> 
> v=0
> ...
> m=audio 49170 RTP/AVP 0
> m=video 51372 RTP/AVP 31
> m=application 32416 udp wb
> ...
> 
> and
> v=0
> ...
> m=audio 49170 RTP/AVP 0
> ...
> v=0
> ...
> m=video 51372 RTP/AVP 31
> ...
> v=0
> ...
> m=application 32416 udp wb
> ...
> 
> It would allow a UA to make more intelligent decisions on what SDP to
> reply with, if some codecs are more desirable than others (say, because of
> hardware decoding).
> 
> Phil
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

---

From: [email-masked]
Date: Tue, 18 Jul 2000 10:30:39 -0600

From my perspective, it is highly desirable for each of the legs of a
multiparty 3pcc call to act like an individual, normal call, to the degree
that such is possible. Bundling session information for several legs into a
single INVITE, for example, makes it difficult for any application
intelligence in the network to govern the behavior of say, two out of five
legs; the closer the legs look to normal calls, the easier it is to reuse
infrastructure that manages normal calls to handle these more advanced
cases. I think this method also provides the greatest flexibility for both
the corrollation and differentiation of each of the legs.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Philip Levis [mailto:[email-masked]]
Sent: Tuesday, July 18, 2000 12:09 PM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: Re: [SIP] Multiple sessions in SDP payload

On Tue, 18 Jul 2000, Jonathan Rosenberg wrote:

> Well, this isn't how it works.
> 
> Multiple media streams in SDP means exactly that, multiple media
> streams. Thats the usage in SAP, thats been the usage for SIP. I don't
> want to change this. If you want alternatives for the same stream, you
> list multiple codecs on the same m line. Thats the defined usage.

You are correct. A closer reading of 2327 even states that the desired
functionality (preference) is already present in SDP:

"When a list of payload formats is given, this implies that all of
these formats may be used in the session, but the first of these
formats is the default format for the session." (pg. 20)

In light of this, I agree that that the presence of multiple SDP sessions
is not useful (at least, in any circumstance I can come up with).

Phil