If A says 97 and B says 101,
B must send using payload 97
A must send using payload 101

They work like ports:
If A says port 10000 and B says port 20000
B must send to port 10000
A must send to port 20000


   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.

The paragraph I quoted is a SHOULD and SHOULDs should always be adhered
to unless
there is a really good reason for not doing so.  It is risky to not
comply with SHOULD.
For best interop, always implement "SHOULD" requirements.

So if A says 97, B should also say 97 but if it doesn't, A must use the
PT specified by B.





________________________________

From: Socaciu, Vlad [mailto:Vlad.Socaciu@unis...]
Sent: 14 September 2009 01:39
To: Attila Sipos; Stefan Sayer
Cc: sip-implementors@list...
Subject: RE: [Sip-implementors] RFC 2833 Telephone-Event RTP Payload
Type



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:attila.sipos@vega...]
Sent: Sunday, September 13, 2009 6:59 AM
To: Stefan Sayer; Socaciu, Vlad
Cc: sip-implementors@list...
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: sip-implementors-bounces@list... on behalf of Stefan
Sayer
Sent: Fri 9/11/2009 3:26 PM
To: Socaciu, Vlad
Cc: sip-implementors@list...
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
> Sip-implementors@list...
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@list...
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

.

_______________________________________________
Sip-implementors mailing list
Sip-implementors@list...
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors