Subject: Re: [AVT] [Sip-implementors] overloading static RTP payload types with dynamic payload types

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 1 Sep 2009 23:02:03 +0200

Amy,
you shouldn't look in SIP specs, rather to RTP itself.
See RFC 3550, in particular § 13 on "RTP Profiles and Payload Format Specifications".

Thus, the usage (binding) of PT values should be defined by an RTP profile.
And your "m=" line refers to the RTP "AVP" Profile (= RFC 3551).

Your question is thus related to RFC 3551 in my opinion.
-Albrecht 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Vikram Chhibber
> Sent: Montag, 24. August 2009 20:22
> To: Amy Hwang
> Cc: [email-masked]
> Subject: Re: [Sip-implementors] overloading static RTP 
> payload types withdynamic payload types
> 
> IMO, it is legal to define a static payload type as dynamic 
> too. The RTP payload type must be 97 for RTP that is being 
> sent out. The SDP answer might have a changed value of the 
> payload type. For more details please refer to Section 5.1 of 
> RFC 3264. Here is an excerpt:
> 
> For recvonly RTP streams, the payload type numbers indicate the value
>    of the payload type field in RTP packets the offerer is 
> expecting to
>    receive for that codec.  For sendonly RTP streams, the payload type
>    numbers indicate the value of the payload type field in RTP packets
>    the offerer is planning to send for that codec.  For sendrecv RTP
>    streams, the payload type numbers indicate the value of the payload
>    type field the offerer expects to receive, and would 
> prefer to send.
>    However, for sendonly and sendrecv streams, the answer 
> might indicate
>    different payload type numbers for the same codecs, in which case,
>    the offerer MUST send with the payload type numbers from 
> the answer.
> 
> On Mon, Aug 24, 2009 at 8:26 AM, Amy 
> Hwang<[email-masked]> wrote:
> >
> > Let's say SDP is offered with the following media line:
> >
> > m=audio 12345 RTP/AVP 97
> > a=rtpmap:97 PCMU/8000
> >
> > That is, a dynamic payload type of 97 is being used to 
> represent PCMU/8000, which is also mapped to the static 
> payload type of 0 by RFC 3551. If this offer is accepted, 
> then would the resulting RTP stream contain a payload type of 0 or 97?
> >
> > I've been scouring through RFC's 3261, 3264, 3550, and 
> 3551, and they seem to imply that it should probably be 97, 
> but I can't seem to find a concrete statement saying that the 
> RTP payload type MUST be 0 or MUST be 97. If someone could 
> also point out where that is, that would be great.
> >
> > Thanks,
> > Amy
> >
> > _________________________________________________________________
> > Get back to school stuff for them and cashback for you.
> > 
> http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB
> > _BackToSchool_Cashback_BTSCashback_1x1
> > _______________________________________________
> > Sip-implementors mailing list
> > [email-masked]
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> 
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>