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

[Jonathan Rosenberg <[e-mail]>]

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

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com

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