Re: SDP telephone-event (DTMF) payload negotiation

On 11/22/11 6:25 PM, RUOFF, LARS (LARS)** CTR ** wrote:
> 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

> Regards,
> Lars
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Paul Kyzivat
> Sent: vendredi 18 novembre 2011 13:04
> To: [email protected]
> Subject: Re: [Sip] SDP telephone-event (DTMF) payload negotiation
>
> On 11/18/11 4:22 PM, RUOFF, LARS (LARS)** CTR ** wrote:
>> 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.
>
>    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 [email protected] for questions on how to develop a SIP implementation.
> Use [email protected] for new developments on the application of sip.
> Use [email protected] 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 [email protected] for questions on how to develop a SIP implementation.
> Use [email protected] for new developments on the application of sip.
> Use [email protected] 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 [email protected] for questions on how to develop a SIP implementation.
Use [email protected] for new developments on the application of sip.
Use [email protected] for issues related to maintenance of the core SIP specifications.