RE: [Sip] Support for Multipart/MIME

"Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com> Thu, 10 May 2007 04:54 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0fK-0001l9-8a; Thu, 10 May 2007 00:54:10 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm0fI-0001l4-SC for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 00:54:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0fI-0001kw-Ii for sip@ietf.org; Thu, 10 May 2007 00:54:08 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm0fH-0005bS-Tx for sip@ietf.org; Thu, 10 May 2007 00:54:08 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3CD3B2092A; Thu, 10 May 2007 06:54:07 +0200 (CEST)
X-AuditID: c1b4fb3c-a8cebbb0000073d5-a6-4642a56fdace
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 325BF208AB; Thu, 10 May 2007 06:54:07 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 06:54:07 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Support for Multipart/MIME
Date: Thu, 10 May 2007 06:54:01 +0200
Message-ID: <7374777208BDC7449D5620EF9423256703F224D6@esealmw113.eemea.ericsson.se>
In-Reply-To: <0db901c792bb$753389c0$c4a36b80@amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Support for Multipart/MIME
Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwAAA6cWw
References: <7374777208BDC7449D5620EF9423256703F22476@esealmw113.eemea.ericsson.se> <0db901c792bb$753389c0$c4a36b80@amer.cisco.com>
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: Dan Wing <dwing@cisco.com>, Dale.Worley@comcast.net
X-OriginalArrivalTime: 10 May 2007 04:54:07.0113 (UTC) FILETIME=[3D797F90:01C792BF]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi, 

Comment at the end.

> > >Using the same port number on multiple m= lines has been, and 
> > >continues to be, a direct violation of several SDP 
> specifications.  
> > >Even the SDP grouping specification explicitly calls this out as 
> > >illegal.
> > 
> > Yes. But in the multipart/alternative example I gave you 
> (and which is 
> > ilustrated in a simple form below) would have 3 individual 
> SDP bodies, 
> > and the same port number would not be used within a single 
> SDP bodies.
> > 
> > But, the same port number would be used in each indivudual 
> SDP body, 
> > and as far as I know there is no specification which forbids that.
> > 
> > -----boundary
> > 
> > m=audio 9999 audio_x
> > m=video 7777 video_x
> > 
> > -----boundary
> > 
> > m=video 7777 video_y
> > 
> > -----boundary
> > 
> > m=audio 9999 audio_y
> > 
> > -----boundary--
> 
> This can be expressed with MMUSIC's capabilities negotiation, 
> though -- and can be expressed better than with 
> multipart/alternative because MMUSIC's capability negotiation 
> defines preferences of each m= and each a= line, whereas 
> multipart/alternative can only ever allow simple "take all of 
> this SDP" or "take none of this SDP".
> 
> (With the specific example you show, of course, you don't 
> even need MMUSIC's capabilities negotiation -- an answerer 
> that doesn't support video (or doesn't support audio) can 
> already indicate that in its SDP answer.)

The point is that, depending on what media the answerer chooses,
different codecs can be used for chosen media streams.

Yes, "vanilla" SDP allows me to offer audio and video, and the answerer
can incdicate what it does/doesn't support. But, vanilla SDP does not
allow the offer to say: "Here is audio and video. If you accept both
then let's use these codecs, but if you only choose audio then let's use
theis other codec". 

Regards,

Christer






> 
> -d
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip