Re: [MMUSIC] RTSP transport header, port parameter changes

Magnus Westerlund <magnus.westerlund@era.ericsson.se> Mon, 10 February 2003 13:33 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08346 for <mmusic-archive@odin.ietf.org>; Mon, 10 Feb 2003 08:33:46 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ADgAK15824 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 08:42:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADgAp15821 for <mmusic-web-archive@optimus.ietf.org>; Mon, 10 Feb 2003 08:42:10 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08338 for <mmusic-web-archive@ietf.org>; Mon, 10 Feb 2003 08:33:14 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADg5p15813; Mon, 10 Feb 2003 08:42:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADfAp15786 for <mmusic@optimus.ietf.org>; Mon, 10 Feb 2003 08:41:10 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08316 for <mmusic@ietf.org>; Mon, 10 Feb 2003 08:32:14 -0500 (EST)
Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1ADZtAv016851; Mon, 10 Feb 2003 14:35:55 +0100 (MET)
Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7MWTCX8; Mon, 10 Feb 2003 14:35:55 +0100
Message-ID: <3E47AABB.4090907@era.ericsson.se>
Date: Mon, 10 Feb 2003 14:35:55 +0100
X-Sybari-Trust: 1c66f42b 9ffcebbb 7a95d2f4 00000138
From: Magnus Westerlund <magnus.westerlund@era.ericsson.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: IETF MMUSIC WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] RTSP transport header, port parameter changes
References: <3E43D4EC.4090600@era.ericsson.se> <3E47A644.6010800@dynamicsoft.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Jonathan,

No, currently it is not possible to specify a separate IP address for 
the RTCP port in respect to the RTP port. I understand that this will 
create problems if a NAT would assign the RTP and RTCP udp flow mappings 
to different public addresses. Have you any knowledge how usual this 
behavior is for NATs?

It is of course possible to solve, even rather easy at least for RTP. 
However the general case of specifying n address/port for server 
respective client would require some more work. To allow for this 
behavior in a general case would be best solved with totally new 
parameters.

Best Regards

Magnus

Jonathan Rosenberg wrote:

> Can a separate IP address be specified for RTCP, as the port can? 
> draft-ietf-mmusic-sdp4nat has this capability, and its needed for 
> cases where the network is natting into more than one IP address.
>
> -Jonathan R.
>
> Magnus Westerlund wrote:
>
>> Hi,
>>
>> At the wednesdays telecon we discussed on how to update the transport 
>> header to support STUN and symmetric RTP
>> for traversal of NATs. It was decided to allow the ports to be 
>> specified explicitly for RTP and RTCP. Therefore I have written up a 
>> proposal for new text for the transport header below:
>>
>> We where discussing making the port attributes totally flexible. 
>> However as I started looking at the section I discovered that port, 
>> client_port, server_port are RTP-specific. So my proposed changes 
>> does therefore only solves what is necessary for RTP. An alternative 
>> to this change would be to reclassify the port attributes to be 
>> general attributes and then they should have total flexibility. That 
>> would also require some text on how to related to the RTP media 
>> transport setup.
>>
>> I also included a client_ssrc parameter. This would be used for 
>> symmetric RTP to make the symmetric port opening more robust. I will 
>> try to write up a mail regarding using symmetric RTP for RTSP sessions.
>>
>> Please read and comment
>>
>> Magnus
>>
>> --------------------------------------------------------
>> changed parts of section 12.40 Transport header in relation to 
>> draft-ietf-mmusic-rfc2326bis-02.txt.
>>
>> RTP-specific:
>>
>>   These parameters are only valid if the media transport protocol  is
>>   RTP.  The parameters containing port numbers are all subject to the
>>   following consideration:  All port numbers where prior specified as
>>   a value or range, see "old-port-spec" in ABNF below. To support NAT
>>   traversal RTP has been updated to allow non-continuous port specif-
>>   ication  not  following  the even/odd rule. As long as both the RTP
>>   and RTCP port is specified explicitly they are allow  to  take  any
>>   valid  port  number. Therefore the RTP specific port parameters has
>>   been updated to support this. The updated format  ("new-port-spec")
>>   SHOULD  only  be  used when required to specify non-continuous port
>>   numbers. Before using the "new-port-spec" format  the  client  MUST
>>   determine server support of the "play.basic" option tags.
>>
>>   port: This parameter provides the RTP/RTCP port pair for  a  multi-
>>        cast  session.  This  parameter  SHOULD NOT use the "new-port-
>>        spec" format. It is should be  specified  as  a  range,  e.g.,
>>        port=3456-3457
>>
>>   client_port: This parameter provides the unicast RTP/RTCP port pair
>>        on  the  client where media data and control information is to
>>        be sent. It is specified either as a range,  e.g.,  port=3456-
>>        3457 or as two explicit numbers port=3457/4976
>>
>>   server_port: This parameter provides the unicast RTP/RTCP port pair
>>        on  the  server where media data and control information is to
>>        be sent. It is specified either as a range,  e.g.,  port=3456-
>>        3457 or as two explicit numbers port=3457/4976
>>
>>   ssrc: The ssrc parameter indicates the RTP  SSRC  [23]  value  that
>>        should  be  (request)  or will be (response) used by the media
>>        server. This parameter is only valid for unicast transmission.
>>        It identifies the synchronization source to be associated with
>>        the media stream, and is expressed as an eight  digit  hexide-
>>        cimal value. In cases that a sender will use multiple SSRCs it
>>        SHOULD NOT use this parameter.
>>
>>   client_ssrc: The client_ssrc parameter indicates the RTP SSRC  [23]
>>        value  that will be used by the client. This parameter is only
>>        valid for unicast transmission. It identifies the synchroniza-
>>        tion  source  to  be  associated with the media stream, and is
>>        expressed as an eight digit hexidecimal value. In cases that a
>>        client  will use multiple SSRCs it SHOULD NOT use this parame-
>>        ter.
>>
>>
>>   Transport                =  "Transport" ":" 1#transport-spec
>>   transport-spec           =  transport-id *parameter
>>   transport-id             =  transport-protocol "/" profile ["/" 
>> lower-transport]
>>                               ; no LWS is allowed inside transport-id
>>   transport-protocol       =  "RTP" / token
>>   profile                  =  "AVP" / token
>>   lower-transport          =  "TCP" / "UDP" / token
>>   parameter                =  ";" ( "unicast" / "multicast" )
>>                           /   ";" "source" "=" address
>>                           /   ";" "destination" [ "=" address ]
>>                           /   ";" "interleaved" "=" channel [ "-" 
>> channel ]
>>                           /   ";" "append"
>>                           /   ";" "ttl" "=" ttl
>>                           /   ";" "layers" "=" 1*DIGIT
>>                           /   ";" "port" "=" port-spec
>>                           /   ";" "client_port" "=" port-spec
>>                           /   ";" "server_port" "=" port-spec
>>                           /   ";" "ssrc" "=" ssrc
>>                           /   ";" "client_ssrc" "=" ssrc
>>                           /   ";" "mode" "=" mode-spec
>>                           /   ";" trn-parameter-extension
>>   port-spec                =  old-port-spec / new-port-spec
>>   old-port-spec            =  port [ "-" port ]
>>   new-port-spec            =  port "/" port ; RTP/RTCP port
>>   trn-parameter-extension  =  par-name "=" trn-par-value
>>   par-name                 =  token
>>   trn-par-value            =  *unreserved
>>   ttl                      =  1*3(DIGIT)
>>   port                     =  1*5(DIGIT)
>>   ssrc                     =  8*8(HEX)
>>   channel                  =  1*3(DIGIT)
>>
>>   address                  =  host ;As defined in RFC 2732 [30]
>>   mode-spec                =  <"> 1#mode <"> / mode
>>
>>
>

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic