Re: [Sip] SDP telephone-event (DTMF) payload negotiation

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 23 November 2011 17:36 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sip@ietfa.amsl.com
Delivered-To: sip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6581111E80B1 for <sip@ietfa.amsl.com>; Wed, 23 Nov 2011 09:36:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.133
X-Spam-Level:
X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyHvzH-T2+d1 for <sip@ietfa.amsl.com>; Wed, 23 Nov 2011 09:36:32 -0800 (PST)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC7C11E80A5 for <sip@ietf.org>; Wed, 23 Nov 2011 09:36:32 -0800 (PST)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id 0hFh1i00217dt5G5DhcYK3; Wed, 23 Nov 2011 17:36:32 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id 0hcY1i00G07duvL3ZhcYhq; Wed, 23 Nov 2011 17:36:32 +0000
Message-ID: <4ECD2F23.3050309@alum.mit.edu>
Date: Thu, 24 Nov 2011 01:36:35 +0800
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: sip@ietf.org
References: <23C6087F32FB3A43941E25922F87538E21E92EA810@FRMRSSXCHMBSA2.dc-m.alcatel-lucent.com> <4EC649B2.8060605@alum.mit.edu> <23C6087F32FB3A43941E25922F87538E21E933C567@FRMRSSXCHMBSA2.dc-m.alcatel-lucent.com>
In-Reply-To: <23C6087F32FB3A43941E25922F87538E21E933C567@FRMRSSXCHMBSA2.dc-m.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Sip] SDP telephone-event (DTMF) payload negotiation
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Nov 2011 17:36:33 -0000

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: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: vendredi 18 novembre 2011 13:04
> To: sip@ietf.org
> 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 sip-implementors@cs.columbia.edu for questions on how to develop a SIP implementation.
> Use dispatch@ietf.org for new developments on the application of sip.
> Use sipcore@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-implementors@cs.columbia.edu for questions on how to develop a SIP implementation.
> Use dispatch@ietf.org for new developments on the application of sip.
> Use sipcore@ietf.org for issues related to maintenance of the core SIP specifications.
>