[MMUSIC] SDP Miscellaneous capabilities: port numbers

<Simo.Veikkolainen@nokia.com> Fri, 25 January 2013 08:17 UTC

Return-Path: <Simo.Veikkolainen@nokia.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EF221F8AD8 for <mmusic@ietfa.amsl.com>; Fri, 25 Jan 2013 00:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu+f+FTTItXn for <mmusic@ietfa.amsl.com>; Fri, 25 Jan 2013 00:17:39 -0800 (PST)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id BDE4E21F8AD4 for <mmusic@ietf.org>; Fri, 25 Jan 2013 00:17:38 -0800 (PST)
Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0P8HGRH017292; Fri, 25 Jan 2013 10:17:34 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jan 2013 10:17:33 +0200
Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.203]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0318.003; Fri, 25 Jan 2013 08:17:32 +0000
From: Simo.Veikkolainen@nokia.com
To: mmusic@ietf.org
Thread-Topic: SDP Miscellaneous capabilities: port numbers
Thread-Index: Ac360/A5tRLGpMVQTqKylTouellYSg==
Date: Fri, 25 Jan 2013 08:17:31 +0000
Message-ID: <D09DAE6B636851459F7575D146EFB54B1C826B64@008-AM1MPN1-026.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-version: 3.3.8.1
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: 2PrCjJ7f5poVv9TjWbkmkpoe9l+M2b40XgaWX2HvB6x+8ekxW/hH5w4lCNi8B0ok5c1YO1LpkfKUqmsRiLvW0+Sb09T+Fkh54VSRVgwD5SFZAOYQERo/r6YDoLilvhsz6J87/P5sV/UXN8QF+H4fTkByjmTMArdbjRh/GK8PHRq6dzOnRI+g+Z8EDZ/BZiQ0R8KH0OnXZ4apXeWiGS8TKR9gezR4H5s2CaSxTeVxbU0iaL5vjghCzKG+aacaT4pO
x-originating-ip: [172.21.81.94]
Content-Type: multipart/alternative; boundary="_000_D09DAE6B636851459F7575D146EFB54B1C826B64008AM1MPN1026mg_"
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Jan 2013 08:17:33.0173 (UTC) FILETIME=[6CF6B250:01CDFAD4]
X-Nokia-AV: Clean
Subject: [MMUSIC] SDP Miscellaneous capabilities: port numbers
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jan 2013 08:17:40 -0000

Dear WG,

An issue came up during review of http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-03 . Figures 6 to 8 present an example SDP which uses the "a=ccap" connection address capability to present two alternative SDP configurations, one for IP based media, and the other for PSTN based media.

The issue is that these two alternative configurations use a different port number. However, there is currently no way to indicate alternative port numbers using the SDP capability negotiation mechanism.

For PSTN based media, the port number does not carry any meaningful information, and http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-15 proposes to use a fixed port number (9, the discard port) which is to be ignored at reception. So, in this particular example we can add a note that since the alternative offered media uses a PSTN bearer, the port should be hardcoded to "9" by the implementer. However, for other types of media this does not work, nor is the example usable in the case where PSTN media is included in the "m=" line, and the address for alternative RTP based media using the "a=ccap" attribute.

In order to fix the issue, probably something like "port capability attribute" should be defined. This has been discussed in the past, but it has its own challenges (because of overlap with ICE, among other things).

The authors' proposal consist of adding a paragraph in the example description where we indicate that this particular example works because the CS description uses a well-known port number, but in general, the example is not applicable if the negotiated capabilities require a change in the port number.

Regards,
Simo & Miguel