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
- [MMUSIC] RTSP transport header, port parameter ch… Magnus Westerlund
- Re: [MMUSIC] RTSP transport header, port paramete… Tom Marshall
- Re: [MMUSIC] RTSP transport header, port paramete… Magnus Westerlund
- Re: [MMUSIC] RTSP transport header, port paramete… Jonathan Rosenberg
- Re: [MMUSIC] RTSP transport header, port paramete… Magnus Westerlund