SDP telephone-event (DTMF) payload negotiation

[RUOFF, LARS (LARS)** CTR **]

Hi all,

New to this list. Apologies if this question has been asked many times before (my searches showed that it has, but i was still unable to find a definitive answer).

The question is about SDP telephone-event (DTMF) payload negotiation.

Imagine the following call setup between A and B:
INVITE A->B
SDP:
(among other media formats)
a=sendrecv
a=rtpmap:101 telephone-event/8000

200 OK B->A
SDP:
(among other media formats)
a=sendrecv
a=rtpmap:97 telephone-event/8000

The question is:
Is the above legal? I.e. is B allowed to choose a different PT than proposed y A.
In case yes, what PT should the telephone-events be sent...
from A to B?
from B to A?

Please corroborate your answers by providing normative references if possible.

I studied RFC 3264 (SDP Offer/Answer Model) intensively, but could not conclude for a definitive answer in that particular case.

Regards,
Lars Ruoff
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Paul Kyzivat]

Post by RUOFF, LARS (LARS)** CTR **
Hi all,
New to this list. Apologies if this question has been asked many times before (my searches showed that it has, but i was still unable to find a definitive answer).
The question is about SDP telephone-event (DTMF) payload negotiation.
INVITE A->B
(among other media formats)
a=sendrecv
a=rtpmap:101 telephone-event/8000
200 OK B->A
(among other media formats)
a=sendrecv
a=rtpmap:97 telephone-event/8000
Is the above legal? I.e. is B allowed to choose a different PT than proposed y A.
In case yes, what PT should the telephone-events be sent...
from A to B?
from B to A?
Please corroborate your answers by providing normative references if possible.
I studied RFC 3264 (SDP Offer/Answer Model) intensively, but could not conclude for a definitive answer in that particular case.

From section 6.1:

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. Even if the same
payload type number is used, the answer MUST contain rtpmap
attributes to define the payload type mappings for dynamic payload
types, and SHOULD contain mappings for static payload types. The
media formats in the "m=" line MUST be listed in order of preference,
with the first format listed being preferred. In this case,
preferred means that the offerer SHOULD use the format with the
highest preference from the answer.
...
Once the answerer has sent the answer, it MUST be prepared to receive
media for any recvonly streams described by that answer. It MUST be
prepared to send and receive media for any sendrecv streams in the
answer, and it MAY send media immediately. The answerer MUST be
prepared to receive media for recvonly or sendrecv streams using any
media formats listed for those streams in the answer, and it MAY send
media immediately. When sending media, it SHOULD use a packetization
interval equal to the value of the ptime attribute in the offer, if
any was present. It SHOULD send media using a bandwidth no higher
than the value of the bandwidth attribute in the offer, if any was
present. The answerer MUST send using a media format in the offer
that is also listed in the answer, and SHOULD send using the most
preferred media format in the offer that is also listed in the
answer. In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer.

From section 7:

When the offerer receives the answer, it MAY send media on the
accepted stream(s) (assuming it is listed as sendrecv or recvonly in
the answer). It MUST send using a media format listed in the answer,

From the above, "the same payload type number SHOULD be used", so its
possible that a different payload type is used. And if so,

- the answerer must send with the pt listed in the offer
- the offerer must send with a media format listed in the answer

It doesn't quite say that the offerer must send with a pt listed in the
answer, but its clear for consistency that it should. That is widely
understood to be the intent.

Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[RUOFF, LARS (LARS)** CTR **]

Thanks, Paul.

It doesn't quite say that the offerer must send with a pt listed in the answer, but its clear for consistency that it should. That is widely understood to be the intent.

That's how I understood it, too. But it seems that opinions diverge on this.
Maybe the RFC authors should insist on the above a bit more explicitely.

Regards,
Lars

-----Original Message-----
From: sip-***@ietf.org [mailto:sip-***@ietf.org] On Behalf Of Paul Kyzivat
Sent: vendredi 18 novembre 2011 13:04
To: ***@ietf.org
Subject: Re: [Sip] SDP telephone-event (DTMF) payload negotiation

Hi all,
New to this list. Apologies if this question has been asked many times before (my searches showed that it has, but i was still unable to find a definitive answer).
The question is about SDP telephone-event (DTMF) payload negotiation.
INVITE A->B
(among other media formats)
a=sendrecv
a=rtpmap:101 telephone-event/8000
200 OK B->A
(among other media formats)
a=sendrecv
a=rtpmap:97 telephone-event/8000
Is the above legal? I.e. is B allowed to choose a different PT than proposed y A.
In case yes, what PT should the telephone-events be sent...
from A to B?
from B to A?
Please corroborate your answers by providing normative references if possible.
I studied RFC 3264 (SDP Offer/Answer Model) intensively, but could not conclude for a definitive answer in that particular case.

From section 6.1:

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. Even if the same
payload type number is used, the answer MUST contain rtpmap
attributes to define the payload type mappings for dynamic payload
types, and SHOULD contain mappings for static payload types. The
media formats in the "m=" line MUST be listed in order of preference,
with the first format listed being preferred. In this case,
preferred means that the offerer SHOULD use the format with the
highest preference from the answer.
...
Once the answerer has sent the answer, it MUST be prepared to receive
media for any recvonly streams described by that answer. It MUST be
prepared to send and receive media for any sendrecv streams in the
answer, and it MAY send media immediately. The answerer MUST be
prepared to receive media for recvonly or sendrecv streams using any
media formats listed for those streams in the answer, and it MAY send
media immediately. When sending media, it SHOULD use a packetization
interval equal to the value of the ptime attribute in the offer, if
any was present. It SHOULD send media using a bandwidth no higher
than the value of the bandwidth attribute in the offer, if any was
present. The answerer MUST send using a media format in the offer
that is also listed in the answer, and SHOULD send using the most
preferred media format in the offer that is also listed in the
answer. In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer.

From section 7:

When the offerer receives the answer, it MAY send media on the
accepted stream(s) (assuming it is listed as sendrecv or recvonly in
the answer). It MUST send using a media format listed in the answer,

From the above, "the same payload type number SHOULD be used", so its possible that a different payload type is used. And if so,

- the answerer must send with the pt listed in the offer
- the offerer must send with a media format listed in the answer

It doesn't quite say that the offerer must send with a pt listed in the answer, but its clear for consistency that it should. That is widely understood to be the intent.

Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Paul Kyzivat]

Post by RUOFF, LARS (LARS)** CTR **
Thanks, Paul.

It doesn't quite say that the offerer must send with a pt listed in the answer, but its clear for consistency that it should. That is widely understood to be the intent.

That's how I understood it, too. But it seems that opinions diverge on this.
Maybe the RFC authors should insist on the above a bit more explicitely.

In retrospect, yes. But the RFC has been published already.
You can file an errata report. That will probably be queued pending a
revision to the RFC.

Thanks,
Paul

Post by RUOFF, LARS (LARS)** CTR **
Regards,
Lars
-----Original Message-----
Sent: vendredi 18 novembre 2011 13:04
Subject: Re: [Sip] SDP telephone-event (DTMF) payload negotiation

Hi all,
New to this list. Apologies if this question has been asked many times before (my searches showed that it has, but i was still unable to find a definitive answer).
The question is about SDP telephone-event (DTMF) payload negotiation.
INVITE A->B
(among other media formats)
a=sendrecv
a=rtpmap:101 telephone-event/8000
200 OK B->A
(among other media formats)
a=sendrecv
a=rtpmap:97 telephone-event/8000
Is the above legal? I.e. is B allowed to choose a different PT than proposed y A.
In case yes, what PT should the telephone-events be sent...
from A to B?
from B to A?
Please corroborate your answers by providing normative references if possible.
I studied RFC 3264 (SDP Offer/Answer Model) intensively, but could not conclude for a definitive answer in that particular case.

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. Even if the same
payload type number is used, the answer MUST contain rtpmap
attributes to define the payload type mappings for dynamic payload
types, and SHOULD contain mappings for static payload types. The
media formats in the "m=" line MUST be listed in order of preference,
with the first format listed being preferred. In this case,
preferred means that the offerer SHOULD use the format with the
highest preference from the answer.
...
Once the answerer has sent the answer, it MUST be prepared to receive
media for any recvonly streams described by that answer. It MUST be
prepared to send and receive media for any sendrecv streams in the
answer, and it MAY send media immediately. The answerer MUST be
prepared to receive media for recvonly or sendrecv streams using any
media formats listed for those streams in the answer, and it MAY send
media immediately. When sending media, it SHOULD use a packetization
interval equal to the value of the ptime attribute in the offer, if
any was present. It SHOULD send media using a bandwidth no higher
than the value of the bandwidth attribute in the offer, if any was
present. The answerer MUST send using a media format in the offer
that is also listed in the answer, and SHOULD send using the most
preferred media format in the offer that is also listed in the
answer. In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer.
When the offerer receives the answer, it MAY send media on the
accepted stream(s) (assuming it is listed as sendrecv or recvonly in
the answer). It MUST send using a media format listed in the answer,
From the above, "the same payload type number SHOULD be used", so its possible that a different payload type is used. And if so,
- the answerer must send with the pt listed in the offer
- the offerer must send with a media format listed in the answer
It doesn't quite say that the offerer must send with a pt listed in the answer, but its clear for consistency that it should. That is widely understood to be the intent.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.