o Socaciu, Vlad [09/11/09 01:35]:
> I found the following question raised by Mr. Greg Dykes on Sun Sep 28:
> My question really is about the actual usage of a numeric payload type
> indicator. The assumption with my question is that both SIP UAs are
> negotiating the same "telephone-event' RTP payload. As I understand
> each SIP UA can specify their own payload type indicator (96-127)
> which represents a specific, static "telephone-event" RFC 2833 RTP
> payload. In other words, they don't have to make use of the same
> value. So am I correct in saying that each SIP UA can indeed make use
> of a different payload type indicator in the dynamic range of 96-127?
> And if so does this value represent the UA's intended RTP payload type
> for SENDING or RECEIVING RTP?
> - Greg
> It seems to be a very clear and pertinent question. But there are no other messages on this thread. I am facing the same dilemma. Can someone provide a resolution?
Have a look at SDP offer/answer RFC,
http://www.ietf.org/rfc/rfc3264.txt, 5.1 Unicast Streams; what is said
there applies to telephone-event payload as with any other dynamic
payload. Here about the offerer:
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.