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

Harald Alvestrand <harald@alvestrand.no> Wed, 09 January 2013 22:52 UTC

Return-Path: <harald@alvestrand.no>
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 AD53621F8DEB for <mmusic@ietfa.amsl.com>; Wed, 9 Jan 2013 14:52:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Level:
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 rtGzkboA2xSY for <mmusic@ietfa.amsl.com>; Wed, 9 Jan 2013 14:52:05 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A689621F8D35 for <mmusic@ietf.org>; Wed, 9 Jan 2013 14:52:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AAD6439E2A2 for <mmusic@ietf.org>; Wed, 9 Jan 2013 23:52:02 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyQl1jHMq9ut for <mmusic@ietf.org>; Wed, 9 Jan 2013 23:52:01 +0100 (CET)
Received: from [83.145.61.137] (unknown [83.145.61.137]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5866139E241 for <mmusic@ietf.org>; Wed, 9 Jan 2013 23:52:01 +0100 (CET)
Message-ID: <50EDF490.4000101@alvestrand.no>
Date: Wed, 09 Jan 2013 23:52:00 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com>
In-Reply-To: <1.77712513fa3f074cccef@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 22:52:07 -0000

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.