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

Emil Ivov <emcho@jitsi.org> Thu, 10 January 2013 23:54 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 22EB221F8799 for <mmusic@ietfa.amsl.com>; Thu, 10 Jan 2013 15:54:46 -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 rD1vSBL8SYLd for <mmusic@ietfa.amsl.com>; Thu, 10 Jan 2013 15:54:44 -0800 (PST)
Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id AB3D521F8501 for <mmusic@ietf.org>; Thu, 10 Jan 2013 15:54:44 -0800 (PST)
Received: by mail-pb0-f52.google.com with SMTP id ro2so595435pbb.39 for <mmusic@ietf.org>; Thu, 10 Jan 2013 15:54:44 -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=EeuPfvsP5IXIfwwYjeW9RrJq8yug6DL59PL+8f4/66U=; b=ZxQzmDQRk7kYBWf8bqxJ3Ej4X/CwnTNhBqMcHvZaf8UxcVdqisAq5nL15K1YBDm6mu 75wXVyFOH74n0m7OhTiP0Gbqpjv6PhebFez4lsAmPUBrrVup/T4szNT+h3rsjSDiK+9c XOGFTeC/cIlR9mJKWa0ipMUmtsA+j9vG9wXGxrk7Hy9pFc0aaQpRPC/q78jaNILY6Jg/ z8Cx9DdkqbIDu39Wn2qlqetEaga0MbblDrl9gX09saGxCsKHU/tawaHLzCH9dCqxRVle nO5QlI1qmily5O2/qsYioKAIR7Oot9c+E2FXwLQ/q2CFsgT9RcCleliYyKHvK0c94cbH PPNw==
X-Received: by 10.68.223.131 with SMTP id qu3mr222980467pbc.89.1357862084303; Thu, 10 Jan 2013 15:54:44 -0800 (PST)
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by mx.google.com with ESMTPS id sb3sm1600845pbc.44.2013.01.10.15.54.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jan 2013 15:54:44 -0800 (PST)
Received: by mail-pa0-f52.google.com with SMTP id fb1so650812pad.25 for <mmusic@ietf.org>; Thu, 10 Jan 2013 15:54:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.66.86.101 with SMTP id o5mr202532764paz.15.1357862083128; Thu, 10 Jan 2013 15:54:43 -0800 (PST)
Received: by 10.66.150.6 with HTTP; Thu, 10 Jan 2013 15:54:43 -0800 (PST)
Received: by 10.66.150.6 with HTTP; Thu, 10 Jan 2013 15:54:43 -0800 (PST)
In-Reply-To: <1.a70a7a76ba63b579d824@cisco.com>
References: <50EDC40F.3010501@alvestrand.no> <1.77712513fa3f074cccef@cisco.com> <50EDF490.4000101@alvestrand.no> <50EE0139.8000909@jitsi.org> <1.3841c28e488bfa397d5b@cisco.com> <1.96f025c482c091c166cc@jitsi.org> <1.a70a7a76ba63b579d824@cisco.com>
Date: Fri, 11 Jan 2013 00:54:43 +0100
Message-ID: <CAPvvaaK3giYg1gOvT1_naEe25mBaJTgWq2P6WfhAZ_HRhL3CiQ@mail.gmail.com>
From: Emil Ivov <emcho@jitsi.org>
To: "Charles Eckel, (eckelcu)" <eckelcu@cisco.com>
Content-Type: multipart/alternative; boundary="f46d042de8071e6d3b04d2f7e7fa"
X-Gm-Message-State: ALoCoQlLTpUAgBxTZH6hGQDZyze7AKIJQyJHXsCzwGIJFm8Vp5sKCwp4H/GKa3nVuRKmt4p66pEp
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:54:46 -0000

On Jan 11, 2013 12:48 AM, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
wrote:
>
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> > Behalf Of Emil Ivov
> > Sent: Thursday, January 10, 2013 3:37 PM
> > To: Charles Eckel (eckelcu)
> > Cc: mmusic
> > Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
> >
> >
> >
> >
> > 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?
>
> This part:
>
> 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.

This part just says the PT numbers can be different in the offer and the
answer. It doesn't say they can be the same as other PT numbers that were
assigned to other formats, which is what section 8.3.2 prohibits.

This is the reason I was seeing 8.3.2 more as a completion rather than a
contradiction.

Emil
--sent from my mobile

>
> Cheers,
> Charles
>
> > 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
> >
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic