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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 07 Feb 2003 16:46:52 +0100

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: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Tom Marshall <[email-masked]>
Date: Fri, 7 Feb 2003 08:39:52 -0800

> server_port are RTP-specific.

Yes, 2326 does say that client_port and server_port are for RTP.  I would
like to propose that the wording be changed, as client_port is not specific
to RTP.  The RealNetworks client and server have been using the client_port
attribute with non-RTP transports since 2326 was written.

-- 
I used to think I was a child; now I think I am an adult -- not because
I no longer do childish things, but because those I call adults are no
more mature than I am.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Feb 2003 09:42:10 +0100

Hi Tom,

I am willing to make the client_port parameters to general parameters. 
It will make their BNF slightly more complicated as they should allow 
for any number of ports, both as ranges and lists. This change will also 
require us to write some text on usage of RTP with general parameter.

Best Regards

Magnus

Tom Marshall wrote:

>>We where discussing making the port attributes totally flexible.
>>    
>>
>However 
>  
>
>>as I started looking at the section I discovered that port,
>>    
>>
>client_port, 
>  
>

-- 

Magnus Westerlund

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Feb 2003 08:16:52 -0500

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.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Feb 2003 14:35:55 +0100

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:

> 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,
>>
>> 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:
>>
>> 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.
>>
>> 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
>>

-- 

Magnus Westerlund