Subject: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment?

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Nov 2013 23:39:23 +0000

Hi,

In Vancouver we decided that an Offerer MUST NOT assign a shared address (with a non-zero port) to multiple m- lines until the Answerer, within the session, has indicated support of BUNDLE.

I suggest the following piece of text to implement  the decision in the BUNDLE spec:

	"The Offerer MUST NOT assign a shared address with a non-zero port
   	value to multiple "m=" lines until it has, within the given session,
   	received an SDP Answer indicating that the Answerer supports the
   	BUNDLE mechanism."

Note that there will be specific text regarding the usage of port zero for 'bundle-only' m- lines.

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 12 Nov 2013 23:20:07 -0800

Hi Christer

Looks good to me. Except, I am assuming "shared address" is defined in the
spec somewhere. I might have missed it as well.

Cheers
Suhas

On Tue, Nov 12, 2013 at 3:39 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> In Vancouver we decided that an Offerer MUST NOT assign a shared address
> (with a non-zero port) to multiple m- lines until the Answerer, within the
> session, has indicated support of BUNDLE.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Nov 2013 16:25:34 +0000

Hi Suhas,

I will add an explicit definition of "shared address" to the next version of the draft.

Regards,

Christer

Lähettäjä: Suhas Nandakumar [mailto:[email-masked]]
Lähetetty: 13. marraskuuta 2013 9:20
Vastaanottaja: Christer Holmberg
Kopio: [email-masked]
Aihe: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment?

Hi Christer

Looks good to me. Except, I am assuming "shared address" is defined in the spec somewhere. I might have missed it as well.

Cheers
Suhas

On Tue, Nov 12, 2013 at 3:39 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Nov 2013 10:02:11 -0800

Christer,

This works for me except for one thing: the word "session", which I fear 
is sufficiently ambiguous to present trouble.

I suggest using "multi-media session". (We can't use "SIP session" or 
"SIP dialog" because this might be used without SIP.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Nov 2013 18:42:35 +0000

Hi Paul,

> This works for me except for one thing: the word "session", which I fear is sufficiently ambiguous to present trouble.
>
> I suggest using "multi-media session". (We can't use "SIP session" or "SIP dialog" because this might be used without SIP.)

I agree regarding not being able to use SIP terminology.

I guess "multi-media session" is one option. What about "SDP session"?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Nov 2013 11:14:11 -0800

> I guess "multi-media session" is one option. What about "SDP session"?

I thought about that. I'm not in love with multi-media session.

When I look at 4566 I find a definition of "session" as multi-media 
session. I think "SDP session" gets the point across, though I have not 
seen "SDP session" used anywhere else.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Nov 2013 19:32:11 +0000

Hi,

> When I look at 4566 I find a definition of "session" as multi-media session. I think "SDP session" gets the point across, though I have not seen "SDP session" used anywhere else.

We could even say "SDP session (e.g. a SIP dialog)"

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 13 Nov 2013 14:43:15 -0800

Hi Christer

  If it helps, I might point you to the Taxonomy document to see if there
is a terminology from that document that better fits the purpose for naming
here

http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-00

Cheers
Suhas

On Wed, Nov 13, 2013 at 11:32 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >>> This works for me except for one thing: the word "session", which I
> fear is sufficiently ambiguous to present trouble.
> >>>
> >> In Vancouver we decided that an Offerer MUST NOT assign a shared
> address (with a non-zero port) to multiple m- lines until the Answerer,
> within the session, has indicated support of BUNDLE.
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Nov 2013 16:19:48 -0800

On 11/13/13 2:43 PM, Suhas Nandakumar wrote:
> Hi Christer
>
>    If it helps, I might point you to the Taxonomy document to see if
> there is a terminology from that document that better fits the purpose
> for naming here
>

I don't think the taxonomy is particularly helpful here.
(Maybe it should be.)

The concept we are after is at the extreme upper boundary of what the 
taxonomy considers. It has a definition of multimedia session, and also 
mentions definitions from 4566 and 3550. They are all quite similar, but 
not identical.

Our use here is, I think, roughly a subset of the 4566 definition, where 
there are only two participants. But it might not actually be so. It is 
unclear in those definitions whether the participants are the senders 
and receivers of signaling, or the senders and receivers of media. 
Often, but not always, they are the same. For the purposes of this draft 
we want to be talking about the senders and receivers of the SDP offers 
and answers.

It may be necessary to create a definition for the purpose.

	Thanks,
	Paul

> Cheers
> Suhas
>
>
> On Wed, Nov 13, 2013 at 11:32 AM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>      >>> This works for me except for one thing: the word "session",
>     which I fear is sufficiently ambiguous to present trouble.
>      >>>
>      > When I look at 4566 I find a definition of "session" as
>     multi-media session. I think "SDP session" gets the point across,
>     though I have not seen "SDP session" used anywhere else.
>
>     address (with a non-zero port) to multiple m- lines until the
>     Answerer, within the session, has indicated support of BUNDLE.
>      >>
>      >> [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 14 Nov 2013 12:44:55 +0000

Christer,

is there any connection between the subject line and the content of this mail threat about putting the shared address into the offer? I'm a bit confused.

Separate from this I want to clarify if the 2nd offer/answer exchange as indicated in the subject line is just used in SIP environments in order to do the usual intermediary "appeasement".
Would the second offer/answer also be required for the WebRTC case where just have two browser client being connect via the same WebRTC server and no further intermediaries?

Kind Regards
Thomas Stach

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Mittwoch, 13. November 2013 20:14
> To: Christer Holmberg; [email-masked]
> Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2
> Offer/Answers during session establishment?
> 
> >> I suggest using "multi-media session". (We can't use "SIP session"
> or "SIP dialog" because this might be used without SIP.)
> >

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 12:52:53 +0000

Hi Thomas,

>From a BUNDLE perspective, the 2nd Offer is always mandated. BUNDLE currently does not define different rules for specific environments.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

"Stach, Thomas" <[email-masked]> wrote:

Christer,

Kind Regards
Thomas Stach