IETF Logo Mail Archive

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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Wed, 09 January 2013 21:01 UTC

Return-Path: <eckelcu@cisco.com>
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 C258F21F88B4 for <mmusic@ietfa.amsl.com>; Wed, 9 Jan 2013 13:01:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.974
X-Spam-Level:
X-Spam-Status: No, score=-9.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8]
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 ZxoaOrP2Ohdu for <mmusic@ietfa.amsl.com>; Wed, 9 Jan 2013 13:01:46 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AE2C021F8645 for <mmusic@ietf.org>; Wed, 9 Jan 2013 13:01:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2416; q=dns/txt; s=iport; t=1357765306; x=1358974906; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EfF/V/jQ1Pm3JhYtD6SQY5G049bnC3ZY6vW9HHxp8gk=; b=YxKJb7rTsqRpu7/OyAf0cWleMrUdIngxaDibGDg+UOb2Rf4DMspc+hZl fRFRbfgL4jBFCUe8/3RkhRdpi6vZdoINhdym9D8isfMbgR3otpdjwwyo8 4gYoavRlWPxlwFW1GFgH9pHLd+243pPecfPWEBAoGJ2KY2H7Pz5NV+Iea c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAGXZ7VCtJV2b/2dsb2JhbABEvVwWc4IeAQEBAwEBAQE3NBAHBAIBCBEEAQELFAkHJwsUCQgCBAESCIgLBQEMtjcEkDlhA6ZVgnSCJA
X-IronPort-AV: E=Sophos;i="4.84,440,1355097600"; d="scan'208";a="160669686"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 09 Jan 2013 21:01:42 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r09L1g8K029494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jan 2013 21:01:42 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.224]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:01:42 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Harald Alvestrand <harald@alvestrand.no>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Query: payload type collision with offer/answer
Thread-Index: AQHN7p8Pzrd89LSrqUC7n2O8JcktGJhBeXIg
Date: Wed, 09 Jan 2013 21:01:41 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C0882804723EE3@xmb-aln-x08.cisco.com>
References: <50EDC40F.3010501@alvestrand.no>
In-Reply-To: <50EDC40F.3010501@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [171.68.20.12]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 21:01:47 -0000

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.

That said there are additional requirements placed on payload type usage by some codecs, such as SVC.

Cheers,
Charles

 
>                     Harald
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

v2.20.3 | Report a Bug | By Email