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

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 18 November 2011 12:04 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 84DF921F8B21 for <sip@ietfa.amsl.com>; Fri, 18 Nov 2011 04:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 cK350MMEQ7lJ for <sip@ietfa.amsl.com>; Fri, 18 Nov 2011 04:04:12 -0800 (PST)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 89FC321F88AB for <sip@ietf.org>; Fri, 18 Nov 2011 04:04:12 -0800 (PST)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA11.westchester.pa.mail.comcast.net with comcast id ybzX1h00A1uE5Es5Bc4DhE; Fri, 18 Nov 2011 12:04:13 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([203.69.99.17]) by omta16.westchester.pa.mail.comcast.net with comcast id yc421h0110NWYwj3cc46Jz; Fri, 18 Nov 2011 12:04:11 +0000
Message-ID: <4EC649B2.8060605@alum.mit.edu>
Date: Fri, 18 Nov 2011 20:04:02 +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>
In-Reply-To: <23C6087F32FB3A43941E25922F87538E21E92EA810@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: Fri, 18 Nov 2011 12:04:13 -0000

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