Re: [MMUSIC] RID update (draft-pthatcher-mmusic-rid-01,> )

"Mo Zanaty (mzanaty)" <> Fri, 16 October 2015 04:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5C6161B2E55 for <>; Thu, 15 Oct 2015 21:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 yk6kb-A0Is-d for <>; Thu, 15 Oct 2015 21:01:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C31F51B2E54 for <>; Thu, 15 Oct 2015 21:01:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2205; q=dns/txt; s=iport; t=1444968082; x=1446177682; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DYl69EHKiNFLCMBu9+7idB/86tn149vvrH/J9yM5NPU=; b=LbfOoW53OE1HDkCWMeFp4lV/Fa66Qnpy0wBOu/Tq3mpk5diu50gBnoL3 D9YLY93QcjnQpPVC5Dy7FCRlrncD/zxSis34p6qyex5NLcxgmd8U+MXWZ s33nc+ATY4azR14rn5YC+BK/VpqqtaO1zAqqdcAYZbWUaCuO4BK8UDRMY k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,687,1437436800"; d="scan'208";a="198422175"
Received: from ([]) by with ESMTP; 16 Oct 2015 04:01:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t9G41LCw025029 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2015 04:01:21 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 23:01:06 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 23:01:06 -0500
From: "Mo Zanaty (mzanaty)" <>
To: Paul Kyzivat <>
Thread-Topic: [MMUSIC] RID update (draft-pthatcher-mmusic-rid-01,> )
Thread-Index: AQHRB79Um1qONMBWjEKhR6WEvDVrFp5tfxGP
Date: Fri, 16 Oct 2015 04:01:06 +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] RID update (draft-pthatcher-mmusic-rid-01,> )
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: Fri, 16 Oct 2015 04:01:24 -0000

See Mo: comments inline. 

On Oct 15, 2015, at 11:04 PM, Paul Kyzivat <> wrote:

* Section 7.1:


1. It MUST generate a 'rid-identifier' that is unique within a media

IIUC, the rid-identifier must be unique within an RTP session, including all the media descriptions pertaining to that RTP session.

Mo: When using bundle, MID maps to unique m sections, so RID must only uniquely identify the streams within an m section. When not bundled, the transport maps to unique m sections, so again RID must only uniquely identify the streams within an m section. Perhaps some text on this would be useful to add. 

* Section 7.2.2, item 2:

Restating my earlier comment, why not simply check the PT against those listed in the m-line? There could be default PTs in use that have no rtpmap or fmtp. Those are only defined for audio, but there *could* be rid constraints applied to audio. (I think max-br would potentially be applicable. Or new ones might be defined that apply.) At least it seems harmless to define it this way.

Mo: Agreed, good idea. 

* Section 7.4, item 4:

I think there should be a check that the PTs in the answer are a subset of those in the offer.

Mo: That seems like a basic O/A thing. Does each draft with any mention of PT need to echo this?

(And, while it can be inferred, it might be good to state somewhere that in cases where the answerer m-line PT values differ from those in the offer, the PTs in the answer rid use the offerer's PT values.)

Mo: I would like to hear opinions on this. Whether the answer rid should use offer or answer PTs. 

* Section 10:

As somebody noted, it is confusing to have ";" separate multiple PT *values* within rid-fmt-list, and also to separate rid-params.

Possible solutions:
- use a different separator for fmt values
- use a different separator for params
- use a "pt=" for *each* fmt.

Mo: Agreed, the syntax needs to be cleaned up a bit. 


mmusic mailing list