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

From: Itamar Gilad <[email-masked]>
Date: Tue, 18 Jul 2000 18:15:55 +0300

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tue, July 18, 2000 5:17 PM
> To: Christian Huitema
> Cc: 'William Lee'; 'Philip Levis'; [email-masked]
> Subject: Re: [SIP] Multiple sessions in SDP payload
> 
> 
> 
> Christian Huitema wrote:
> > The problem is, there is a fundamental contradiction 
> between two requirements. If I include 3 "m=audio" lines, do 
> they describe
> > 3 ways to pass audio, such as IPv4, IPv6 and POTS, or do I 
> describe 3 audio channels that should be deployed in parallel? My
> > take so far would be to use multiple instance of the same 
> media within a single SDP payload to describe alternative encodings,
> > and to use multiple SDP payloads, using MIME multipart, to 
> encode several parallel sessions.
> 
> I think three lines of the same type means the same thing it does in
> SAPs usage - parallel media streams, not alternatives. This, 
> in fact, is
> necessary as per the other thread on sending DTMF using 
> rfc2833 to third
> party application servers.
> 
> 
> 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.
> 
> -Jonathan R.

I agree. RFC 2543 1.3 defines Call and Session as follows:

        Call: A call consists of all participants in a conference
             invited by a common source. A SIP call is identified by a
             globally unique call-id (Section 6.13)...

        Session: From the SDP specification: "A multimedia session is a
             set of multimedia senders and receivers and the data
             streams flowing from senders to receivers. A multimedia
             conference is an example of a multimedia session." (RFC
             2327 [6]) (A session as defined for SDP can comprise one or
             more RTP sessions.) As defined, a callee can be invited
             several times, by different calls, to the same session. If
             SDP is used, a session is defined by the concatenation of
             the user name , session id , network type , address type
             and address elements in the origin field.

This I believe implies that a SIP Call and a SDP session have a one-to-one
relationship identified by the Call-ID in SIP and the (single) o= line in
the SDP session section.
 
 Itamar

> 
> >        -----Original Message-----
> >        From: William Lee [mailto:[email-masked]]
> >        Sent: Monday, July 17, 2000 10:15 PM
> >        To: 'Philip Levis'
> >        Cc: [email-masked]
> >        Subject: RE: [SIP] Multiple sessions in SDP payload
> > 
> >        Yes, according to the spec, multiple SDP sessions 
> may be specified.  
> >        At the 2nd SIP bake-off, we tested a trial 
> implementation of our 
> >        SDP parser/statemachine that sent and received 
> multiple SDP sessions. 
> >        No one supported this, and as far as I know no one 
> else does today. 
> 
> 
> 
> -- 
> 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
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Philip Levis <[email-masked]>
Date: Tue, 18 Jul 2000 09:41:32 -0600 (MDT)

> relationship identified by the Call-ID in SIP and the (single) o= line in

It may imply that, but I don't think it makes any sense.

2543bis:

"A Call consisists of all participants in a conference united by a common
source. A SIP call is identified by a globally unique Call-ID."

In 3pcc, there are multiple parties invited with different SDPs from one
source. Being from one source, each call leg may have the same Call-ID,
yet different SDPs. This is especially true in the case of a central media
server, in which parties may have different media capabilities.

Phil