Re: [MMUSIC] Query: payload type collision with offer/answer

Emil Ivov <emcho@jitsi.org> Wed, 09 January 2013 23:46 UTC

Return-Path: <emil@sip-communicator.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A09A21F8476 for <mmusic@ietfa.amsl.com>; Wed, 9 Jan 2013 15:46:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1UsCsYhQa7g for <mmusic@ietfa.amsl.com>; Wed, 9 Jan 2013 15:46:07 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4708921F8475 for <mmusic@ietf.org>; Wed, 9 Jan 2013 15:46:06 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id dq12so1338171wgb.12 for <mmusic@ietf.org>; Wed, 09 Jan 2013 15:46:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=RBQGh3DCQyFLXqUEKxsN5Uz5HnrDf66olhTjS1GZJ1U=; b=A6WK7rKNCmjthAB8mD69ZuMh/IQBuW3Io03ddxV6tmobXWsDIgL0rUCd9pWc9B1wsU MmEWq2hJWVoqG5CjTwJttcFMO8VqtDbTxTCxjubOQnjVC+DqvzxAK7bDxvaiuVfaKtEa 5jtQ5BiwZ0NZj2cIoLEllTQm0cTBW6m2pfZx7D40Ht0JGzCsVk0euUfQHot3Yq/N18fk F7mAaxHQ42EDkdQ/aGJKLo6wPoZvpDIVs6mYIfdksgO2DNcmAPkg6iC8RHrHmXcJf0aU 3E8W8KoZRuFb53O5h9ooxzXcgT9szg1lWqFCJEAR7Kn7gr9rK4g9Kn0fztVviCr4mOua YY6Q==
X-Received: by 10.194.235.100 with SMTP id ul4mr111681769wjc.7.1357775165857; Wed, 09 Jan 2013 15:46:05 -0800 (PST)
Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPS id l5sm6637754wia.10.2013.01.09.15.46.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Jan 2013 15:46:04 -0800 (PST)
Message-ID: <50EE0139.8000909@jitsi.org>
Date: Thu, 10 Jan 2013 00:46:01 +0100
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no>
In-Reply-To: <50EDF490.4000101@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQm3MskF8xFW2AVBRWiXw/GvFyn//rGhPZ2HajY5OG+pdahY4yrkE0vA1n6xdoAvcwO7Bw9j
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2013 23:46:08 -0000

On 09.01.13, 23:52, Harald Alvestrand wrote:
> On 01/09/2013 10:01 PM, Charles Eckel (eckelcu) wrote:
>> Please see inline.
>>
>>> -----Original Message-----
>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>>> Behalf Of Harald Alvestrand
>>> Sent: Wednesday, January 09, 2013 11:25 AM
>>> To: mmusic@ietf.org
>>> Subject: [MMUSIC] Query: payload type collision with offer/answer
>>>
>>> Hello,
>>> I have encountered an issue, and I'm not sure it's an issue or not. SDP
>>> wisdom is sought.
>>>
>>> Suppose two entities exchange the following offer/answer:
>>>
>>> offer from X:
>>>
>>> m=video 97
>>> a=rtpmap:97 foo
>>>
>>> answer from Y:
>>>
>>> m=video 98
>>> a=rtpmap:98 foo
>>>
>>> It's clear from RFC 3264 that now X must send codec foo with payload
>>> type 98, and Y must send codec foo with payload type 97. That's not the
>>> question.
>>>
>>> But suppose these are the offer and answer:
>>>
>>> offer from X:
>>>
>>> m=video 97 98
>>> a=rtpmap:97 foo
>>> a=rtpmap:98 bar
>>>
>>> answer from Y:
>>>
>>> m=video 97 98
>>> a=rtpmap:97 bar
>>> a=rtpmap:98 foo
>>>
>>> That is, the payload types collide.
>>>
>>> It would be possible to write code so that X sends foo with 98 and bar
>>> with 97, while Y sends foo with 97 and bar with 98. But is it 
>> conformant
>>> with the specs to do so?
>>>
>>> And if this has a clear answer - which paragraph of which RFC makes 
>> this
>>> clear?
>>> (Yes, this discussion is triggered from a real world problem.)
>>
>> It is recommended to avoid such mismatches when possible, but doing so 
>> may not always be possible. The examples you mention are conformant. 
>> The following text from section 5.1 addresses this:
>>
>> 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.
>>
>> Different payload type numbers may be needed in each direction
>> because of interoperability concerns with H.323.
> I was reading that text, and it clearly says which ones to use if the 
> payload types are different, but I don't think they clearly address the 
> situation with using the same payload type for two different codecs in 
> different directions.
> 
> In a multicast or transport relay scenario, this would clearly be 
> untenable, since third parties would not be able to send streams that 
> would be interpreted correctly by the two conflicting endpoints, but in 
> a two-party conversation, it's possible to make this work.
> I just don't know if it's worth the effort to make it so.

Well there's also section 8.3.2 in 3264. The section is about updating
offers but it seems like the text explicitly prohibits remapping payload
types in any scenarios:

   However, in the
   case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session.  For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session.  However, it is
   acceptable for multiple payload type numbers to be mapped to the same
   codec, so that an updated offer could also use payload type number 72
   for G.711.

Cheers,
Emil


-- 
https://jitsi.org