Re: [MMUSIC] Simulcast draft feedback

"Mo Zanaty (mzanaty)" <> Mon, 19 October 2015 22:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D57E91B2DFD for <>; Mon, 19 Oct 2015 15:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FViYXvqSalIg for <>; Mon, 19 Oct 2015 15:40:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 550F71B2DFA for <>; Mon, 19 Oct 2015 15:40:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2026; q=dns/txt; s=iport; t=1445294423; x=1446504023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YP/FqaCkpSW8ftP+LAqYTLRhkgbl6XeHhPKgdJTV29A=; b=miiiYHRTRCcoYiszz7z5D40j42lkR4IvfrgFkrKZ+TRN0GwrXNEpNLT5 pBI4HfiwD2wcljtkpV8uyjO42GpSrYu8vLRzMlzC3yzhfN84o7u4bEosy 81jd0/jONxlRDyTShYUKgNBddfK/H5D3U2A0i+NMLp3ouIH+2a8KmHyT4 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,704,1437436800"; d="scan'208";a="199588838"
Received: from ([]) by with ESMTP; 19 Oct 2015 22:40:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t9JMeMlM025623 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 22:40:22 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 17:40:04 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 17:40:04 -0500
From: "Mo Zanaty (mzanaty)" <>
To: Byron Campen <>
Thread-Topic: [MMUSIC] Simulcast draft feedback
Thread-Index: AQHRCqvt1mCwCO6F50SKnsmEKQlehJ5zs6AAgAAAnQD//7SdSw==
Date: Mon, 19 Oct 2015 22:40:04 +0000
Message-ID: <>
References: <> <>,<>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [MMUSIC] Simulcast draft feedback
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Oct 2015 22:40:26 -0000

The convention for existing SDP attributes is to refer to local media formats (PT for RTP media sections). If the answer uses different PTs for the same format, this can lead to complex format matching rules for local vs remote SDP. While I think everyone dislikes this complexity for the limited benefit of supporting asymmetry in PTs, I think simulcast and rid should just stick with the convention. It would be even greater complexity to have an SDP body refer to local PTs in most areas but remote PTs in a few others (rid and simulcast attributes). 

If we really want to avoid this complexity we need a new attribute like a=symmetric-pt-only independent of simulcast or rid. The complexity is unavoidable without this, because it is a basic thing even in single stream cases which obviously must be supported. There is no way simulcast or rid can avoid this complexity within their own specs. 


On Oct 19, 2015, at 6:10 PM, Byron Campen <> wrote:

> On 10/19/15 5:07 PM, Paul Kyzivat wrote:
>> On 10/19/15 4:22 PM, Byron Campen wrote:
>> **** Payload type asymmetry confusion ****
>>     Consider the following simulcast offer/answer exchange, where the
>> answerer removes a simulcast version and changes payload types:
>> offer:
>> a=rtpmap:96 VP8/90000
>> a=rtpmap:97 VP8/90000
>> a=rtpmap:98 VP8/90000
>> // a=fmtp that differ for the above three
>> a=simulcast: send pt=96;97;98
>> answer:
>> a=simulcast: recv pt=42;101
> I don't understand. I think you need to provide more info. Did it change PTs in the m-line of the answer for codec configs the offerer called 96,97,98? Did it add more PTs not mentioned in the offer?
   It changed the payload types that were present in the offer (same m-section).

Best regards,
Byron Campen

mmusic mailing list