Return-Path: 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 AF35C11E86B6 for ; Mon, 21 Oct 2013 13:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.366 X-Spam-Level: X-Spam-Status: No, score=-5.366 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9guVP7mSAqXg for ; Mon, 21 Oct 2013 13:01:49 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C51B711E8422 for ; Mon, 21 Oct 2013 13:00:50 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-f6-526587f11e86 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 49.1F.03802.1F785625; Mon, 21 Oct 2013 22:00:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 22:00:49 +0200 From: Christer Holmberg To: Adam Roach , "mmusic@ietf.org" Thread-Topic: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN? Thread-Index: Ac7OhpamIvENB/S3QrGtxwOPSJ1SZ///+PCAgAAiIGL///fD3w== Date: Mon, 21 Oct 2013 20:00:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E63CB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4E5FB0@ESESSMB209.ericsson.se>, <52658089.6030008@nostrum.com> In-Reply-To: <52658089.6030008@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4E63CBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje7H9tQgg+ZjxhZ7/i5it5i6/DGL A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWxcPZ0toLHuhU/pm1ga2B8q9rFyMkhIWAi MeFnOyOELSZx4d56ti5GLg4hgcOMEgvfL2OCcJYwSnRv/wHkcHCwCVhIdP/TBjFFBNwk5p1K B+kVFnCQeDF5BSuILSLgKLFh2V9miBInicOz9EDCLAKqEhcndbGA2LwCvhKt6zuYQGwhgRyJ iT+ng53AKaAtcevlcmYQmxHonO+n1oDVMAuIS9x6Mp8J4kwBiSV7zjND2KISLx//YwVZJSGg JDFtaxpEeb7E5kn9UKsEJU7OfMIygVFkFpJJs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1di xr9DUDXWEnMb9jMhq1nAyLGKkT03MTMnvdxoEyMwmg5u+a26g/HOOZFDjNIcLErivB/eOgcJ CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCySC91xYL34u97EoHkiK09t1tias8PRelbKizm9 FWL9N+UCtQ8ePFJ3iDPuooNfm+sCj9zodYkzdq/XUNeJvjmH45ZTzBIO24rA/1FzmwPPFKo2 ZP+fI/T3uvOf34EMTXUXJ/eEuy4zvMZ/50p8j3WgAIN6SthdoRMrdj6KTbqzOpjf5bXZeSWW 4oxEQy3mouJEAG+rIIp0AgAA Subject: Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 20:01:56 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4E63CBESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >> one also needs to specify the location of the m- line mid value in the >> group:BUNDLE mid value list. > > I don't believe that's true. > > The only ordering consideration that I'm aware of for group:BUNDLE is > that the first indicated mid is the one that the transport information > is taken from. If, for whatever reason, the Answerer does not/cannot choose the first in t= he list, it shall try the next in the list, etc. But, that only becomes an issue when the BUNDLE address has yet not been ne= gotiated - or when one tries to re-negotiate it (discussed below). > By the time we're into partial exchanges, the transport > information for all the lines in the same bundle should be identical. ...assuming we don't also want to re-negotiate the BUNDLE address with the = POF, in which case the POF might contain that new address. But, as we discussed earlier, and as you also indicated at the end of your = e-mail, maybe using POF for transport re-negotiation is something we can di= sallow. > To ensure a common view of groups, we probably want to define things > such that new lines added to a group are appended to the list. Is there > any reason you can think this doesn't work for BUNDLE? I need to think about it, but nothing comes to my mind at the moment. And, if both endpoints add a new m- line to the BUNDLE group at the same ti= me, I guess the order in which they mids are appended to the list could be = based on the order in which the m- lines themselves are added to the SDP st= ate. > To be clear, let's set aside the prospect of changing transport > addresses for a BUNDLE: I don't think it's unreasonable to require a > full offer/answer exchange to do that kind of thing. I agree. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4E63CBESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4BE94EE9FCDB714793DB19E844D0D46D@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

>> one also need= s to specify the location of the m- line mid value in the
>> group:BUNDLE mid value list.
>
> I don't believe that's true.
>
> The only ordering consideration that I'm aware of for group:BUNDLE is =
> that the first indicated mid is the one that the transport information=
> is taken from.

 

If, for whatever reaso= n, the Answerer does not/cannot choose the first in the list, it shall try = the next in the list, etc.

 

But, that only becomes= an issue when the BUNDLE address has yet not been negotiated - or when one= tries to re-negotiate it (discussed below).

 

> By the time = we're into partial exchanges, the transport
> information for all the lines in the same bundle should be identical.<= /span>

 

...assuming we don't a= lso want to re-negotiate the BUNDLE address with the POF, in which cas= e the POF might contain that new address.

 

But, as we discussed e= arlier, and as you also indicated at the end of your e-mail, maybe using PO= F for transport re-negotiation is something we can disallow.<= /p>


> To ensure a common view of groups, we probably want to define things <= br> > such that new lines added to a group are appended to the list. Is ther= e
> any reason you can think this doesn't work for BUNDLE?

I need to think about it, but nothing comes to my mind at the moment.

 

And, if both endpoints add a new m- line to the BUNDLE group at the same= time, I guess the order in which they mids are appended to the list could = be based on the order in which the m- lines themselves are added to the SDP= state.


> To be clear, let's set aside the prospect of changing transport
> addresses for a BUNDLE: I don't think it's unreasonable to require a <= br> > full offer/answer exchange to do that kind of thing.

 

I agree.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4E63CBESESSMB209erics_--