Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA411A00A5 for ; Mon, 3 Mar 2014 06:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2en1bTWf-vx3 for ; Mon, 3 Mar 2014 06:40:53 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id E4F561A005E for ; Mon, 3 Mar 2014 06:40:52 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-ff-5314947145ff Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 3B.7E.04853.17494135; Mon, 3 Mar 2014 15:40:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 15:40:48 +0100 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] IETF#89: BUNDLE: Q9: What are the criteria for allowing usage of the same PT value within multiple m- lines? - A new take. Thread-Index: Ac824vtSFLJVCI5rSOGVBTMx34MhTf//+0EA///oubCAACBVAP//7g/A Date: Mon, 3 Mar 2014 14:40:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1C65C8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1C6336@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1C654F@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1C65C8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW7hFJFgg+uLxC2mLn/MYrFzbgez A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXRePg1c8Ei84o7P6cxNjC+Mehi5OSQEDCR 2Nu7ixnCFpO4cG89WxcjF4eQwAlGiab5d1ghnMWMEr87NrF3MXJwsAlYSHT/0wZpEBHQkli9 eC4TSJhZQF3i6uIgkHJhgUmMEsdWTwLrFRGYzCix8+RzNogGN4m7XfNYQWwWARWJ1Ye2soDY vAK+Ej9/XQGrERKYzyTx5Ic6iM0pEChxsG0ZI4jNCHTd91NrmEBsZgFxiVtP5jNBXC0gsWTP eagPRCVePv7HCmErSTQuecIKUZ8vsWjfMXaIXYISJ2c+YZnAKDoLyahZSMpmISmDiOtILNj9 iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxgli1OLi3PTjQz0ctNzS/RSizKTi4vz8/SKUzcxAiPv 4JbfRjsYT+6xP8QozcGiJM57nbUmSEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj1AyndTEF PYV/clbOqZArc01W1/5/KWLBy5NG1fkVabMZL2TNO2he/6s6Knct45KDy2dN1WIsXtwlWneG s/ndR9O+h1vq/Ga77imRufBw6YVV155w6DT7vj8699Uj5ulRapNTC2ZHH+NpiK9U7t97/VlH fOX8vtgCFp+Oq5vvHjiw0yBr240yJZbijERDLeai4kQAfk8SjIoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yfade1wkwoHFD5FSLpEMyRzeuag Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] IETF#89: BUNDLE: Q9: What are the criteria for allowing usage of the same PT value within multiple m- lines? - A new take. X-BeenThere: mmusic@ietf.org 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, 03 Mar 2014 14:40:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1C65C8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, > I think the recommendation in the BUNDLE document should say 2 points > > 1. Reuse of PT is allowed only in the cases where the end-point is able = to uniquely map the > incoming RTP Streams to its corresponding m=3Dline.= The specific mechanisms to do so are > out of the scope of this document= . Informally, SSRC, AppID or similar stream correlators > can be used. But, again, when you send the offer, how do you know what "correlators" the= answerer supports? Should we say that is out of the scope? [Suhas] I am happy with some text similar to here: https://tools.ietf.org/h= tml/draft-roach-mmusic-unified-plan-00#section-3.2. If the Offer/Answer can't prove any mechanism possible, It would imply new = Offer/Answer with unique PTs. I don't see if one can escape the worst-case = scenario though. If people are ok with that, it works for me. I guess that means that we would need a flag in the API to indicate whether= the same PT value can be used or not. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D1C65C8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi= ,

>  I think the recomm= endation in the BUNDLE document should say 2 points

>  

>  1. Reuse of PT is = allowed only in the cases where the end-point is able to uniquely map the >   incoming RTP Streams = to its corresponding m=3Dline. The specific mechanisms to do so are >   out of the scope of t= his document . Informally, SSRC, AppID or similar stream correlators >   can be used.

But, again, when you send the offer, ho= w do you know what “correlators” the answerer supports? Should we say that is out of the scope?=

 

[Suhas] I am happy with some text similar to here:&n= bsp;https://tools.ietf.org/html/draft-roach-mmusic-unified-plan= -00#section-3.2.

 

If the Offer/Answer can't prove any mechanism possib= le, It would imply new Offer/Answer with unique PTs. I don't see if one can= escape the worst-case scenario though.

 

If people are ok with that, i= t works for me.

 

I guess that means that we wo= uld need a flag in the API to indicate whether the same PT value can be use= d or not.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D1C65C8ESESSMB209erics_--