Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Feb 2016 15:15:21 +0000

Hi,

We still need to conclude this issue before we can ship BUNDLE, so I’d like to hear some input from people. I do intend to request agenda time to discuss it in Buenos Aires, but if we can find a solution before that there will be more time for cookies…

Regards,

Christer

From: Peter Thatcher [mailto:[email-masked]]
Sent: 17. marraskuuta 2015 1:06
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

On Mon, Nov 16, 2015 at 2:58 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

>> I thinking mandating the candidates be duplicated in the answer has three issues:
>>
>> 1.  It conflicts with trickle ICE.
>> 2.  It's slightly more complex to implement (we have to go add extra logic to go duplicate these things)
>> 3.  It's a complete waste of time/space/effort.  The recipient of these duplicate candidates is never going to anything with them.
>
> Those are all fair points. I wish we'd had more implementation input when we write our specs.
>
> That's what I'm providing now :).  We can still change the spec, can't we?
​
Sure.

However, as we are talking about a design wise big (in my opinion) change, at a late stage, I'd like to hear what other people think.

​That sounds fair.  I'd like to hear what others think about this.​
​

>>>Also keep in mind that, when a subsequent offer is sent, the bundle-only attribute is no longer used.
>>
​>>Can you point out where in the draft it says that?  I tried finding it and I had a difficult time seeing where bundle-only wasn't allowed in a reoffer.​
​>>
>> Section 8.5.1 says:
>>
>>        "When an offerer generates a subsequent offer, it MUST assign the
>>       previously selected offerer BUNDLE address [Section 8.3.2], to each
>>       bundled "m=" line (including any bundle-only "m=" line), except if:"
>>
>> And, as the usage of the attribute is only defined when the port value is zero, it would not work when the BUNDLE address (read: non-zero port) must be associated with the m- line.
>>
>> Section 6 says:
>>
>>   "The usage of the 'bundle-only' attribute is only defined for a
>>   bundled "m=" line with a zero port value, within an offer.  Other
>>   usage is unspecified."
>
​> Thanks.  That text would be more clear as "with an initial offer" instead of "whithin an offer", since that's what it really means in conjuction with 8.5.1.

Ok.

> However, that's precisely the text that I think we could change.  I think we could change the bundle-only attribute to
> be allowed in answers and in subsequent offers.  Then clients could use the attribute as a way of avoiding duplication
> of candidates and the complications with trickle ICE.​

Assuming we would remove the duplication of candidates, I don't think that would require us to change a semantics of the attribute. We could simply say that the candidates don't need to be duplicated in bundled m- lines, no matter if those m- lines are bundle-only or not.

That would work as well.
​

>>>> Would you then also in the subsequent offer only assign possible candidates to only one m- line within the bundle group?
>>>
​>>> That sounds logical to me.  They aren't included in the first offer.  Why add them to subsequent offers?  It's inconsistent, and a waste.
>>
>> Then someone could ask: what about other (non-candidate) attributes that must have identical values for each bundled m- line? Should those also be assigned to only one of the m- lines?
>
​> If it's something unique to the bundle group, and not the m-line, that seems reasonable to me.  ​
​>
​> But candidates are more painful than those would be because of the interactions with trickle ICE.  If it weren't for trickle ICE this wouldn't be as big of a deal.​

Correct. We just need to make it very clear whether it applies only to candidate attributes, or to attributes with identical values in general.

>>>>>>>> 2.  If the answerer does not include any candidates in the answer and instead trickles them later, should it trickle them
>>>>>>>> N times (once for each m-line in the BUNDLE group) or >1 time?  1 time seems much more reasonable than N times, but
>>>>>>>> if we duplicate candidates in the answer, but not duplicate them while trickling, that's a bit inconsistent.  Yet >another reason to not duplicate in the answer :).
>>>>>>>
>>>>>>> Assuming you use SDP to signal the trickled candidates, it’s true that you would duplicate them,
>>>>>>>
>>>>>>​What's the rationale for that?  These duplicates provide no value, and in the case of many m-lines (such as a conferencing
>>>>>>system with many participants), we could be talking about 30x the number of candidates being signaled.
>>>>
>>>> I hear what you are saying.
>>>>
>>>> But, if we would do a change, we also need to look at the full picture, and consider subsequent offers etc.
>>>
​>>> I think a simple rule would be "if you know it's going to be bundled onto another m-line, don't include
>>> candidates".  That would go for bundle-only m-lines in an offer, bundled m-lines in an answer, and bundled m-lines in a re-offer.​
​>>>
>> Bundled m- lines in a re-offer can still be rejected by the answerer.
>
​> That sounds the same as an initial offer.  How does it imply that a re-offer must duplicate
> candidates across m-lines, even when an initial offer doesn't need to?​
​
In the initial offer each m- line contains candidates (unique). If an m- line in the offer is rejected, the answerer must select the offerer BUNDLE address (and the associated candidiates) from another m- line.

Now, in a re-offer, if the m- line containing the candidates is rejected, the answerer needs to include its candidates in another m- line in the answer. That's doable, but it would need to be clearly documented. In other words: it needs to be clear that the candidates can occur in ANY of the bundled m- lines, and that m- line may change between offers and answers.

​So a rule of "the candidates can be in any one of the m-lines, and it doesn't matter which, and it can change any time".  That seems reasonable to me.  It leave the most flexibility to the one writing the SDP, and it's very easy to implement for the one reading the SDP.​

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Feb 2016 12:19:25 +0000

*sounds of crickets*

Ok, so assuming the scope of this change would only be ICE, we could say that shared ICE candidates don’t have to be associated with each m- line within a BUNDLE group – it’s enough if they are associated with one m- line.

Q1: Does this apply only to the SDP ‘candidate’ attribute, or also to other ICE-related SDP attributes?

Q2: Is it a RECOMMENDED/SHOULD/MAY/MUST/MUST NOT?

Now, if I don’t hear any feedback on this, I am NOT going to do the change. Those who asked for this change (or otherwise have an opinion on it), please speak up now.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 16. helmikuuta 2016 17:15
To: Peter Thatcher
Cc: [email-masked]
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Hi,

Regards,

Christer

From: Peter Thatcher [mailto:[email-masked]]
Sent: 17. marraskuuta 2015 1:06
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

​
Sure.

Ok.

That would work as well.
​

​>>>
​

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Feb 2016 11:40:37 -0500

On 2/18/16 7:19 AM, Christer Holmberg wrote:
> **sounds of crickets**
>
> Ok, so assuming the scope of this change would only be ICE, we could say
> that shared ICE candidates don’t have to be associated with each m- line
> within a BUNDLE group – it’s enough if they are associated with one m- line.

I haven't been following this discussion closely, so forgive me if I 
have misunderstood...

I see how it might be inconvenient to redundantly provide all the 
candidates with each m-line. But at the least this exception will need 
very careful specification, or else it could lead to very confusing 
implementations.

(For instance, different subsets of the candidates associated with 
different m-lines.)

So if this is to be done, I think it should be quite restrictive. 
Perhaps either duplicate candidates with every m-line or else all the 
candidates with only one m-line, and no candidates with any of the other 
m-lines in the bundle. If in all m-lines of the offer then also in all 
accepted m-lines in the answer. If in only one m-line in the offer, then 
only in the corresponding m-line of the answer.

Even then, what is to be done if the candidates are with only one of the 
m-lines in the offer, and the answerer wants to reject *that* m-line but 
accept others in the bundle? Does the answerer pick a different m-line 
to carry the candidates in the answer?

	Thanks,
	Paul

> Now, if I don’t hear any feedback on this, I am NOT going to do the
> change. Those who asked for this change (or otherwise have an opinion on
> it), please speak up now.
>
> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 16. helmikuuta 2016 17:15
> *To:* Peter Thatcher
> *Cc:* [email-masked]
> *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>
> Hi,
>
> We still need to conclude this issue before we can ship BUNDLE, so I’d
> like to hear some input from people. I do intend to request agenda time
> to discuss it in Buenos Aires, but if we can find a solution before that
> there will be more time for cookies…
>
> Regards,
>
> Christer
>
> *From:*Peter Thatcher [mailto:[email-masked]]
> *Sent:* 17. marraskuuta 2015 1:06
> *To:* Christer Holmberg
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>
> On Mon, Nov 16, 2015 at 2:58 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> Hi,
>
>  >> 3.  It's a complete waste of time/space/effort.  The recipient of
> these duplicate candidates is never going to anything with them.
>  >
> However, as we are talking about a design wise big (in my opinion)
> change, at a late stage, I'd like to hear what other people think.
>
>     ​>>Can you point out where in the draft it says that?  I tried
>     finding it and I had a difficult time seeing where bundle-only
>     wasn't allowed in a reoffer.​
>     ​>>
>      >> Section 8.5.1 says:
>      >>
>      >> And, as the usage of the attribute is only defined when the port
>     value is zero, it would not work when the BUNDLE address (read:
>     non-zero port) must be associated with the m- line.
>      >>
>      >> Section 6 says:
>      >>
>     ​> Thanks.  That text would be more clear as "with an initial offer"
>     instead of "whithin an offer", since that's what it really means in
>     conjuction with 8.5.1.
>
>     Ok.
>
>      > However, that's precisely the text that I think we could change.
>     I think we could change the bundle-only attribute to
>      > be allowed in answers and in subsequent offers.  Then clients
>     could use the attribute as a way of avoiding duplication
>     Assuming we would remove the duplication of candidates, I don't
>     think that would require us to change a semantics of the attribute.
>     We could simply say that the candidates don't need to be duplicated
>     in bundled m- lines, no matter if those m- lines are bundle-only or not.
>
> That would work as well.
>
> ​
>
>
>      >>>> Would you then also in the subsequent offer only assign
>     possible candidates to only one m- line within the bundle group?
>      >>>
>     ​>>> That sounds logical to me.  They aren't included in the first
>     offer.  Why add them to subsequent offers?  It's inconsistent, and a
>     waste.
>      >>
>      >> Then someone could ask: what about other (non-candidate)
>     attributes that must have identical values for each bundled m- line?
>     Should those also be assigned to only one of the m- lines?
>      >
>     ​> But candidates are more painful than those would be because of
>     the interactions with trickle ICE.  If it weren't for trickle ICE
>     this wouldn't be as big of a deal.​
>
>     Correct. We just need to make it very clear whether it applies only
>     to candidate attributes, or to attributes with identical values in
>     general.
>
>      >>>>>>>> 2.  If the answerer does not include any candidates in the
>     answer and instead trickles them later, should it trickle them
>      >>>>>>>> N times (once for each m-line in the BUNDLE group) or >1
>     time?  1 time seems much more reasonable than N times, but
>      >>>>>>>> if we duplicate candidates in the answer, but not
>     duplicate them while trickling, that's a bit inconsistent.  Yet
>      >another reason to not duplicate in the answer :).
>      >>>>>>>
>      >>>>>>​What's the rationale for that?  These duplicates provide no
>     value, and in the case of many m-lines (such as a conferencing
>      >>>> But, if we would do a change, we also need to look at the full
>     picture, and consider subsequent offers etc.
>      >>>
>     ​>>> I think a simple rule would be "if you know it's going to be
>     bundled onto another m-line, don't include
>      >>> candidates".  That would go for bundle-only m-lines in an
>     offer, bundled m-lines in an answer, and bundled m-lines in a re-offer.​
>     ​>>>
>     In the initial offer each m- line contains candidates (unique). If
>     an m- line in the offer is rejected, the answerer must select the
>     offerer BUNDLE address (and the associated candidiates) from another
>     m- line.
>
>     Now, in a re-offer, if the m- line containing the candidates is
>     rejected, the answerer needs to include its candidates in another m-
>     line in the answer. That's doable, but it would need to be clearly
>     documented. In other words: it needs to be clear that the candidates
>     can occur in ANY of the bundled m- lines, and that m- line may
>     change between offers and answers.
>
> ​So a rule of "the candidates can be in any one of the m-lines, and it
> doesn't matter which, and it can change any time".  That seems
> reasonable to me.  It leave the most flexibility to the one writing the
> SDP, and it's very easy to implement for the one reading the SDP.​
>
>
>     Regards,
>
>     Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Feb 2016 18:56:02 +0000

Hi Paul,

>> Ok, so assuming the scope of this change would only be ICE, we could 
>> say that shared ICE candidates don’t have to be associated with each 
>> m- line within a BUNDLE group – it’s enough if they are associated with one m- line.
>
> I haven't been following this discussion closely, so forgive me if I have misunderstood...

Don't worry - there hasn't been much discussion :)

> I see how it might be inconvenient to redundantly provide all the candidates with each m-line. But at the least 
> this exception will need very careful specification, or else it could lead to very confusing implementations.

Correct, and that's one reason I suggest that we limit the scope to ICE, eventhough we probably could do the same thing for any IDENTICAL and TRANSPORT category attribute.

> (For instance, different subsets of the candidates associated with different m-lines.)

Note that we are talking about m- lines within a given BUNDLE group, where the same set of shared candidates apply to each m- line. There will be no subset.

> Perhaps either duplicate candidates with every m-line or else all the candidates with only one m-line, and no candidates with any of the other m-lines in the bundle.

We could e.g. say that shared candidates MUST be placed in the m- line representing the BUNDLE address (first mid in the mid list). Then we can either forbid them to be placed elsewhere, or say that they can be discarded if placed elsewhere. 

(Unique candidates must obviously always be explicitly placed in the m- line they belong to.)

> If in all m-lines of the offer then also in all accepted m-lines in the answer. If in only one m-line in the offer, then only in the corresponding m-line of the answer.
>
> Even then, what is to be done if the candidates are with only one of the m-lines in the offer, and the answerer wants to reject *that* m-line but
> accept others in the bundle? Does the answerer pick a different m-line to carry the candidates in the answer?

Mandating the candidates in the m- line representing the BUNDLE address would work, because that m- line always belongs to the BUNDLE group.

Regards,

Christer

> change. Those who asked for this change (or otherwise have an opinion 
> on it), please speak up now.
>
> Regards,
>
> Christer
>
> like to hear some input from people. I do intend to request agenda 
> time to discuss it in Buenos Aires, but if we can find a solution 
> before that there will be more time for cookies…
>
> Regards,
>
> Christer
>
>  >> 2.  It's slightly more complex to implement (we have to go add 
> extra logic to go duplicate these things)  >> 3.  It's a complete 
> waste of time/space/effort.  The recipient of these duplicate 
> candidates is never going to anything with them.
>  >
> reasonable to me.  It leave the most flexibility to the one writing 
> the SDP, and it's very easy to implement for the one reading the SDP.​
>
>
>     Regards,
>
>     Christer
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Feb 2016 11:03:09 -0500

WFM

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Feb 2016 17:03:06 +0000

Peter?

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 19 February 2016 18:03
To: Christer Holmberg <[email-masked]>; [email-masked]; Peter Thatcher <[email-masked]>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

WFM

On 2/18/16 1:56 PM, Christer Holmberg wrote:
>> candidates with each m-line. But at the least this exception will need very careful specification, or else it could lead to very confusing implementations.
>
>> Even then, what is to be done if the candidates are with only one of 
>> the m-lines in the offer, and the answerer wants to reject *that* m-line but accept others in the bundle? Does the answerer pick a different m-line to carry the candidates in the answer?
>
>> *From:*mmusic [mailto:[email-masked]] *On Behalf Of 
>> *Christer Holmberg
>> We still need to conclude this issue before we can ship BUNDLE, so 
>> I’d like to hear some input from people. I do intend to request 
>> agenda time to discuss it in Buenos Aires, but if we can find a 
>> solution before that there will be more time for cookies…
>>
>> Regards,
>>
>> Christer
>>
>> ​So a rule of "the candidates can be in any one of the m-lines, and 
>> it doesn't matter which, and it can change any time".  That seems

---

From: Peter Thatcher <[email-masked]>
Date: Sat, 20 Feb 2016 00:08:22 -0800

On Thu, Feb 18, 2016 at 10:56 AM, Christer Holmberg <
[email-masked]> wrote:

> candidates with each m-line. But at the least
> Correct, and that's one reason I suggest that we limit the scope to ICE,
> eventhough we probably could do the same thing for any IDENTICAL and
> TRANSPORT category attribute.
>

​While it would be nice to remove any duplication, the duplication is
particularly painful for ICE candidates, because there can be a lot of
them, and because they change without any offer/answer action (thanks to
trickle ICE). ​  So if we just covered that candidates, we'd be getting
most of the value.

> Note that we are talking about m- lines within a given BUNDLE group, where
> the same set of shared candidates apply to each m- line. There will be no
> subset.
>
> m-lines in the bundle.
> We could e.g. say that shared candidates MUST be placed in the m- line
> representing the BUNDLE address (first mid in the mid list). Then we can
> either forbid them to be placed elsewhere, or say that they can be
> discarded if placed elsewhere.
>
> > If in all m-lines of the offer then also in all accepted m-lines in the
> answer. If in only one m-line in the offer, then only in the corresponding
> m-line of the answer.
> >
> Mandating the candidates in the m- line representing the BUNDLE address
> would work, because that m- line always belongs to the BUNDLE group.
>
>
Just allowing the candidates to only be in the m-line representing the
BUNDLE is exactly what I was asking for.  If you further *mandate* it, I
can't complain.  Sounds good to me.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Feb 2016 17:57:32 +0000

Hi Peter,

>> Correct, and that's one reason I suggest that we limit the scope to ICE, eventhough we probably 
>> could do the same thing for any IDENTICAL and TRANSPORT category attribute.
>
​> While it would be nice to remove any duplication, the duplication is particularly painful for ICE candidates, because 
> there can be a lot of them, and because they change without any offer/answer action (thanks to trickle ICE). ​  
> So if we just covered that candidates, we'd be getting most of the value.
 
Assuming the scope is ICE, shouldn't the same still apply also to other ICE related attributes? I assume the values for the "remote-candidates",  "ice-lite", "ice-mismatch", "ice-ufrag", "ice-pwd", "ice-pacing" and "ice-options" attributes will be identical within a BUNDLE group, so...

...

> Just allowing the candidates to only be in the m-line representing the BUNDLE is exactly what I was asking for.  If you further *mandate* it, I can't complain.  Sounds good to me.

Unless someone objects, *only* allowing in the m- line representing the BUNDLE address makes things easier :)

(Of course, a good implementation should still be able to handle a case when it receives an offer/answer with the candidates in multiple m- lines within the BUNDLE group.)

Regards,

Christer

>  >> I thinking mandating the candidates be duplicated in the answer
> has three issues:
>  >>
>  >> 1.  It conflicts with trickle ICE.
>  >> 2.  It's slightly more complex to implement (we have to go add
>  >
>  > Those are all fair points. I wish we'd had more implementation
> input when we write our specs.
>  >
>  > That's what I'm providing now :).  We can still change the spec,
> can't we?
> ​
> Sure.
>
>      >>>Also keep in mind that, when a subsequent offer is sent, the
>     bundle-only attribute is no longer used.
>      >>
>      >> Section 8.5.1 says:
>      >>
>      >>        "When an offerer generates a subsequent offer, it MUST
>     assign the
>      >>       previously selected offerer BUNDLE address [Section
>     8.3.2], to each
>      >>       bundled "m=" line (including any bundle-only "m=" line),
>     except if:"
>      >>
>      >> And, as the usage of the attribute is only defined when the port
>      >>
>      >> Section 6 says:
>      >>
>      >>   "The usage of the 'bundle-only' attribute is only defined for a
>      >>   bundled "m=" line with a zero port value, within an offer.  Other
>      >>   usage is unspecified."
>      >
>      > However, that's precisely the text that I think we could change.
>      > be allowed in answers and in subsequent offers.  Then clients
>      > of candidates and the complications with trickle ICE.​
>
>      >>>> Would you then also in the subsequent offer only assign
>      >>>
>      >>
>      >> Then someone could ask: what about other (non-candidate)
>      >
>      >>>>>>>> 2.  If the answerer does not include any candidates in the
>      >>>>>>>> N times (once for each m-line in the BUNDLE group) or >1
>      >>>>>>>> if we duplicate candidates in the answer, but not
>      >another reason to not duplicate in the answer :).
>      >>>>>>>
>      >>>>>>> Assuming you use SDP to signal the trickled candidates,
>     it’s true that you would duplicate them,
>      >>>>>>>
>      >>>>>>​What's the rationale for that?  These duplicates provide no
>      >>>>>>system with many participants), we could be talking about 30x
>     the number of candidates being signaled.
>      >>>>
>      >>>> I hear what you are saying.
>      >>>>
>      >>>> But, if we would do a change, we also need to look at the full
>      >>>
>      >>> candidates".  That would go for bundle-only m-lines in an
>      >> Bundled m- lines in a re-offer can still be rejected by the
>     answerer.
>      >
>      > candidates across m-lines, even when an initial offer doesn't
>     need to?​
>     ​

---

From: Roman Shpount <[email-masked]>
Date: Sun, 21 Feb 2016 01:21:09 -0500

On Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg <
[email-masked]> wrote:

> ​> While it would be nice to remove any duplication, the duplication is
> particularly painful for ICE candidates, because
> > there can be a lot of them, and because they change without any
> offer/answer action (thanks to trickle ICE). ​
> Assuming the scope is ICE, shouldn't the same still apply also to other
> ICE related attributes? I assume the values for the "remote-candidates",
> "ice-lite", "ice-mismatch", "ice-ufrag", "ice-pwd", "ice-pacing" and
> "ice-options" attributes will be identical within a BUNDLE group, so...
>

"ice-lite" and "ice-options" are session level only candidates, so they
should not be in the m= line BUNDLE or any other type. The same logic that
applies to ICe candidates should apply to other media level ICE SDP
attributes or things will break

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Feb 2016 10:12:29 +0000

Hi Roman,

I didn't check whether some of the ICE attributes were session-level, but I agree with what you say: the same rule should apply to all media-level ICE attributes.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎21/‎02/‎2016 08:21
To: Christer Holmberg<mailto:[email-masked]>
Cc: Peter Thatcher<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Paul Kyzivat<mailto:[email-masked]>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

"ice-lite" and "ice-options" are session level only candidates, so they should not be in the m= line BUNDLE or any other type. The same logic that applies to ICe candidates should apply to other media level ICE SDP attributes or things will break

Regards,
_____________
Roman Shpount

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 24 Feb 2016 22:53:02 -0800

That makes sense to me.

On Sun, Feb 21, 2016 at 2:12 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi Roman,
>
> I didn't check whether some of the ICE attributes were session-level, but
> I agree with what you say: the same rule should apply to all media-level
> ICE attributes.
>
> Regards,
>
> Christer
>
> ------------------------------
> From: Roman Shpount <[email-masked]>
> To: Christer Holmberg <[email-masked]>
> Cc: Peter Thatcher <[email-masked]>; [email-masked]; Paul Kyzivat
> <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2016 09:07:37 +0000

Hi Peter,

I submitted a new version (-27) of BUNDLE a few days ago. Could you take a look at the ICE Considerations section, and say whether you are ok with the text?

Thanks!

Regards,

Christer

From: Peter Thatcher [mailto:[email-masked]]
Sent: 25 February 2016 08:53
To: Christer Holmberg <[email-masked]>
Cc: Roman Shpount <[email-masked]>; [email-masked]; Paul Kyzivat <[email-masked]>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

That makes sense to me.

On Sun, Feb 21, 2016 at 2:12 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman,

Regards,

Christer

Regards,
_____________
Roman Shpount

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 26 Feb 2016 13:23:34 -0800

Sure.

On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi Peter,
>
>
>
> I submitted a new version (-27) of BUNDLE a few days ago. Could you take a
> look at the ICE Considerations section, and say whether you are ok with the
> text?
>
>
>
> Thanks!
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Peter Thatcher [mailto:[email-masked]]
> *Sent:* 25 February 2016 08:53
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Roman Shpount <[email-masked]>; [email-masked]; Paul Kyzivat <
> [email-masked]>
>
> *From: *Roman Shpount <[email-masked]>
> *Sent: *‎21/‎02/‎2016 08:21
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *Peter Thatcher <[email-masked]>; [email-masked]; Paul Kyzivat
> <[email-masked]>
> *Subject: *Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>