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

Emil Ivov <emcho@jitsi.org> Thu, 10 January 2013 23:37 UTC

Return-Path: <emcho@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 1ED7E21F8545 for <mmusic@ietfa.amsl.com>; Thu, 10 Jan 2013 15:37:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.376
X-Spam-Level:
X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ATaj+PCfBDo8 for <mmusic@ietfa.amsl.com>; Thu, 10 Jan 2013 15:37:31 -0800 (PST)
Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id AA38F21F8419 for <mmusic@ietf.org>; Thu, 10 Jan 2013 15:37:31 -0800 (PST)
Received: by mail-pb0-f47.google.com with SMTP id un1so586613pbc.6 for <mmusic@ietf.org>; Thu, 10 Jan 2013 15:37:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=skY3VqHndPvB5D2kStI1GhFGRyrSin4MSd3Em1prLbQ=; b=fib1OmjYO4Y120ndF6xBZJpPVfmxnwn6DjXXCcMKEP5pq0L1l4J0CTu7IDNAS0Msn5 hjcYC4KJynDR2zFbE6WSH17lcwFU/OCnNX8iZ0CFNpczw8ZjOS6g26alrz9bjY5hTfZ2 hrRroDpxRRDHqEDc9Xyqp027NVP3nNBli4pYWQG8UgCeDCMU2Gzn122P+wFywklisMsl Lmt4TFvd3NULuCKM7pUuYvzwKwfVbrirZny/ZwAezhAkzpzX+JEtxs1mpOvCoTKQJU42 SNnQOz4gEm5u7p+rmyGU1qMrV606xbe8yfgV4se3jgeI6OtaCZYbN3TJ9CqV3WO2iP9Y /SZQ==
X-Received: by 10.68.244.6 with SMTP id xc6mr224847782pbc.94.1357861051168; Thu, 10 Jan 2013 15:37:31 -0800 (PST)
Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by mx.google.com with ESMTPS id nw9sm1577827pbb.42.2013.01.10.15.37.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jan 2013 15:37:31 -0800 (PST)
Received: by mail-pb0-f41.google.com with SMTP id xa7so585867pbc.14 for <mmusic@ietf.org>; Thu, 10 Jan 2013 15:37:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.191.5 with SMTP id gu5mr223809334pbc.145.1357861050003; Thu, 10 Jan 2013 15:37:30 -0800 (PST)
Received: by 10.66.150.6 with HTTP; Thu, 10 Jan 2013 15:37:29 -0800 (PST)
Received: by 10.66.150.6 with HTTP; Thu, 10 Jan 2013 15:37:29 -0800 (PST)
In-Reply-To: <1.3841c28e488bfa397d5b@cisco.com>
References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <1.3841c28e488bfa397d5b@cisco.com>
Date: Fri, 11 Jan 2013 00:37:29 +0100
Message-ID: <CAPvvaaK1Ort9545YObNYQV=X+_wcnyPZGZsXE0yU=st7Ci4Xwg@mail.gmail.com>
From: Emil Ivov <emcho@jitsi.org>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
Content-Type: multipart/alternative; boundary=e89a8ff1c8ae8a317304d2f7a9e1
X-Gm-Message-State: ALoCoQn0Z/iZedu+C9sk55PmVgLttGp5Eu+L2J4tCuYLu/UsiTbdv/ZH7pLFn2F9U07HATPylAoW
Cc: mmusic <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: Thu, 10 Jan 2013 23:37:33 -0000

On Jan 11, 2013 12:23 AM, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
wrote:
>
> Please see inline.
>
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> > Behalf Of Emil Ivov
> > Sent: Wednesday, January 09, 2013 3:46 PM
> > To: Harald Alvestrand
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
> >
> >
> >
> > 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@ietforg] 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.
>
> I viewed this as being a requirement for all offers or answers sent by
> A to B, but not necessarily the corresponding answer and offers from
> B to A.

Well, it does say: "from that point forward in _any_ offers or answers"

> Otherwise, it seems to conflict with the text in section 5.1.

Mmm ... which part of 5.1?

To me it just seems like a completion (admittedly, somewhat out of place).

> That said, I can certainly see where someone else may interpret it
> differently.

Agreed. Definitely 3264bis material.

Cheers,
Emil

--sent from my mobile
>
> Cheers,
> Charles
>
> > Cheers,
> > Emil
> >
> >
> > --
> > https://jitsi.org
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic