RE: [Sip] Support for Multipart/MIME

"Dan Wing" <dwing@cisco.com> Thu, 10 May 2007 04:27 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 1Hm0F7-0001vi-HG; Thu, 10 May 2007 00:27:05 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm0F5-0001vS-Q8 for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 00:27:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0F5-0001vK-GT for sip@ietf.org; Thu, 10 May 2007 00:27:03 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm0F4-0001v1-6w for sip@ietf.org; Thu, 10 May 2007 00:27:03 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 May 2007 21:27:01 -0700
X-IronPort-AV: i="4.14,515,1170662400"; d="scan'208"; a="146902483:sNHT216350316"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4A4R1lS004143; Wed, 9 May 2007 21:27:01 -0700
Received: from dwingwxp ([10.32.240.197]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4A4R00f012290; Thu, 10 May 2007 04:27:01 GMT
From: Dan Wing <dwing@cisco.com>
To: "'Christer Holmberg (JO/LMF)'" <christer.holmberg@ericsson.com>, Dale.Worley@comcast.net
Subject: RE: [Sip] Support for Multipart/MIME
Date: Wed, 09 May 2007 21:27:02 -0700
Message-ID: <0db901c792bb$753389c0$c4a36b80@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028
In-Reply-To: <7374777208BDC7449D5620EF9423256703F22476@esealmw113.eemea.ericsson.se>
Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwA==
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1365; t=1178771221; x=1179635221; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=n36JDjE3WWq9KxTIne3m8yE5+TH7yXsLSBteG7frBC4=; b=bPAGWxYCmDY5ONidzo89W2y/o05Ms/2cVanlcF2npv9EBJoA3jpR8oFVT3hcxHU6DVO8NIPA 4N7zXTAk4Kx2jsX0Dmhr3ocI7EvXQ/imcSaF6d4u4HkBXprAdlUcJjbh;
Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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

> >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.)

-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