Gentlemen,
Thank you very much for your comments! You saved me the effort to study this
intricate RFC.
I am just a user trying to debug a problem which arose between Avaya and a
Radvision SIP stack. I am using Radvision (indirectly, through Dialogic) and
the customer is using an Avaya SIP PBX.
I tried to summarize the statements from RFC 3264 in the following table. "x"
and "y" are payload type numbers.
Mode Offerer (A) Answerer (B) RTP-Direction PT-number-in-RTP
===============================================================
sendonly x y from A to B y
recvonly x y from B to A x
sendrecv x x from A to B x
sendrecv x x from B to A x
There are two points which are unclear to me:
1. For "recvonly" I showed in the table that the answerer advertised a
different payload type number. Is this legal or the answerer should advertise
the same payload type as the offerer ("x" in this case)?
What should the offerer do, if the answerer specified "y" in its SDP but then
sent the RTP messages correctly using "x" for the PT? Of course, I am trying to
play the devil's advocate.
2. For "sendrecv" the spec seems a little ambiguous or even contradictory.
The paragraph quoted by Attila (page 10) states very clearly that the answerer
should advertise the same payload type number as the offerer. The table above
is based on this assumption. However, the paragraph quoted by Stefan (page 7)
states that
"for... sendrecv streams, the answer might indicate different payload type
numbers for the same codecs".
which seems to contradict the rule at page 10.
It continues:
"...in which case, the offerer MUST send with the payload type numbers from the
answer" (same as for "sendonly").
But the RFC does not say what should the answerer do. Should it use the PT
number that it advertised or the one advertised by the offerer?
In fact this is my problem. Avaya sends PT number 127 in the INVITE and
Radvision answers with PT number 101 in "200 OK". Unfortunately, the RTP
streams do not reach their destinations because of a firewall obstacle and the
customers do not have the chance to exchange DTMF signals.
Thanks a lot and best regards!
________________________________
From: Attila Sipos [mailto:[email protected]]
Sent: Sunday, September 13, 2009 6:59 AM
To: Stefan Sayer; Socaciu, Vlad
Cc: [email protected]
Subject: RE: [Sip-implementors] RFC 2833 Telephone-Event RTP Payload Type
Note also this (also from RFC3264):
In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer.
This means, as an example, that if 97 was used for telephone-events
in the offer, then 97 should be used in the answer.
For best interoperability, comply with the above MUST.
Regards
Attila
-----Original Message-----
From: [email protected] on behalf of Stefan Sayer
Sent: Fri 9/11/2009 3:26 PM
To: Socaciu, Vlad
Cc: [email protected]
Subject: Re: [Sip-implementors] RFC 2833 Telephone-Event RTP Payload Type
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?
>
> Thanks,
>
> - 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.
Best Regards
Stefan
>
> Thanks.
>
> Vlad Socaciu
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
