Subject: [MMUSIC] Questions about ICE candidates with BUNDLE

From: Peter Thatcher <[email-masked]>
Date: Thu, 12 Nov 2015 12:36:25 -0800

While implementing BUNDLE, we ran into a few questions
about draft-ietf-mmusic-sdp-bundle-negotiation-23, especially section 11
and when ICE candidates are included in m-lines:

1.  It says "answerer MUST assign shared ICE candidates to each bundled
'm=' line ... in the answer".  What is the reasoning for duplicating
candidates in this way in the answer?  Clearly at this point, the offerer
understands BUNDLE and BUNDLE is negotiated, and the offerer (when using
bundle-only) doesn't include duplicate candidates, so what's value in
duplicating the candidates in the answer?  If there isn't a good reason,
I'd prefer to not duplicate them, even if that means using 'a=bundle-only'
in the answer (which is currently unspecified)

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 :).

3. (more for editors)  Everything refers to "11.1", but 11.1 doesn't say
much.  Does it mean "11.2.1", which has more substance?

4. (more for editors) 11.2.2 and 11.2.5 are exactly the same.  Why not just
remove 11.2.5 and say 11.2.2 refers to all offers?

Thanks,
Peter

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Nov 2015 21:12:05 +0000

Hi Peter,

>While implementing BUNDLE, we ran into a few questions about draft-ietf-mmusic-sdp-bundle-negotiation-23,
>especially section 11 and when ICE candidates are included in m-lines:
>
>
>1.  It says "answerer MUST assign shared ICE candidates to each bundled 'm=' line ... in the answer".  What is
>the reasoning for duplicating candidates in this way in the answer?  Clearly at this point, the offerer understands
>BUNDLE and BUNDLE is negotiated, and the offerer (when using bundle-only) doesn't include duplicate candidates,
>so what's value in duplicating the candidates in the answer?  If there isn't a good reason, I'd prefer to not duplicate
>them, even if that means using 'a=bundle-only' in the answer (which is currently unspecified)

At an early stage, we made a design decision that we’ll explicitly include all information in each m- line (like we do for non-BUNDLE), even if that means duplicating information.

Otherwise we have to define procedures what happens if the m- line, in which the candidates were included, is e.g. later removed from the BUNDLE group. Then the candidates have to be assigned to some other m- line within the BUNDLE group, to make sure they are “seen” in the current SDP associated with the BUNDLE group. Etc.

>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, but you would still indicate each in a single SDP message sent towards the offerer.

>3. (more for editors)  Everything refers to "11.1", but 11.1 doesn't say much.  Does it mean "11.2.1", which has more substance?
>
>4. (more for editors) 11.2.2 and 11.2.5 are exactly the same.  Why not just remove 11.2.5 and say 11.2.2 refers to all offers?

I have to do some editorial fixes based on comments from Flemming, so I’ll take a look at these at the same time :)

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 12 Nov 2015 18:20:28 -0800

On Thu, Nov 12, 2015 at 1:12 PM, Christer Holmberg <
[email-masked]> wrote:

> about draft-ietf-mmusic-sdp-bundle-negotiation-23,
>
> 'm=' line ... in the answer".  What is
>
> >the reasoning for duplicating candidates in this way in the answer?
> Clearly at this point, the offerer understands
>
> >BUNDLE and BUNDLE is negotiated, and the offerer (when using
> bundle-only) doesn't include duplicate candidates,
>
> >so what's value in duplicating the candidates in the answer?  If there
> isn't a good reason, I'd prefer to not duplicate
>
> At an early stage, we made a design decision that we’ll explicitly include
> all information in each m- line (like we do for non-BUNDLE), even if that
> means duplicating information.
>
>
>
> Otherwise we have to define procedures what happens if the m- line, in
> which the candidates were included, is e.g. later removed from the BUNDLE
> group. Then the candidates have to be assigned to some other m- line within
> the BUNDLE group, to make sure they are “seen” in the current SDP
> associated with the BUNDLE group. Etc.
>

​But that's not true for offers.  Offers can put "a=bundle-only" in the
m-line and then leave out ICE candidates.  So why can't answers do that
also?

​

> m-line in the BUNDLE group) or >1 time?  1 time seems much more reasonable
> duplicate them while trickling, that's a bit inconsistent.  Yet >another
> 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.

> but you would still indicate each in a single SDP message sent towards the
> offerer.
>

The default behavior of trickle ICE webrtc is for the "onicecandidate"
​event ​
to have one candidate in each event, which means the simple WebRTC
application will be signalling
​each candidates individually.  For a single SDP message to contain many
candidates, the application would have to implement some form of candidate
batching.  But a smart application wouldn't bother doing that.  It would
just de-duplicate the candidates instead.  Which means it would just be
counteracting this duplication.

​This seems like just a silly waste to me, especially since it's apparently
only required on the answerer side, and not on the offerer side.​

> >4. (more for editors) 11.2.2 and 11.2.5 are exactly the same.  Why not
> just remove 11.2.5 and say 11.2.2 refers to all offers?
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Nov 2015 22:14:33 +0000

Hi,

>>Otherwise we have to define procedures what happens if the m- line, in which the candidates were included, is e.g. later removed 
>>from the BUNDLE group. Then the candidates have to be assigned to some other m- line within the BUNDLE group, to make sure 
>>they are “seen” in the current SDP associated with the BUNDLE group. Etc.
>
​> But that's not true for offers.  Offers can put "a=bundle-only" in the m-line and then leave out ICE candidates.  So why can't answers do that also?

The reason you don't need to include candidates in a bundle-only m- line is so that you don't need to reserve unique candidates for the m- line (as the m- line is not going to be used unless it's placed in a bundle group, and hence will share the candidates associated with the bundle group). That is not an issue in the answer, as the same candidates can be assigned to each m- line in the bundle group.

Also keep in mind that, when a subsequent offer is sent, the bundle-only attribute is no longer used. Would you then also in the subsequent offer only assign possible candidates to only one m- line within the bundle group?
 
>>> 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.

> but you would still indicate each in a single SDP message sent towards the offerer.
>
​> event ​to have one candidate in each event, which means the simple WebRTC application will be signalling 
​> each candidates individually.  For a single SDP message to contain many candidates, the application would 
> have to implement some form of candidate batching.  But a smart application wouldn't bother doing that. 
> It would just de-duplicate the candidates instead.  Which means it would just be counteracting this duplication.

​> This seems like just a silly waste to me, especially since it's apparently only required on the answerer side, and not on the offerer side.​

Why don't you think it's needed on the offerer side? Are you saying that, in subsequent offers, each m- line would contain duplicated candidates?

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 13 Nov 2015 14:52:32 -0800

On Fri, Nov 13, 2015 at 2:14 PM, Christer Holmberg <
[email-masked]> wrote:

> >>At an early stage, we made a design decision that we’ll explicitly
> include all information in each m- line (like we do for non-BUNDLE), even
> if that means duplicating information.
> >>
> which the candidates were included, is e.g. later removed
> >>from the BUNDLE group. Then the candidates have to be assigned to some
> other m- line within the BUNDLE group, to make sure
> ​> But that's not true for offers.  Offers can put "a=bundle-only" in the
> The reason you don't need to include candidates in a bundle-only m- line
> is so that you don't need to reserve unique candidates for the m- line (as
> the m- line is not going to be used unless it's placed in a bundle group,
> and hence will share the candidates associated with the bundle group).

​In the case of an m-line in an answer that is an answer to a bundle-only
m-line in an offer, the same logic applies:  the m-line is not going to be
used unless it's place in a bundle group, so you don't need to reserve
unique candidates, so you don't need to include any candidates.

> That is not an issue in the answer, as the same candidates can be assigned
> to each m- line in the bundle group.
>
>
​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.

> 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.​
​

> 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.

> 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

​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.​
​

> ​> This seems like just a silly waste to me, especially since it's
> apparently only required on the answerer side, and not on the offerer side.​
>
> Why don't you think it's needed on the offerer side? Are you saying that,
> in subsequent offers, each m- line would contain duplicated candidates?
>
>
​I was referring only to initial offers, where they aren't duplicated.  But
as I mentioned, I think bundle-only m-lines should contain in subsequent
offers should contain the same candidates as the initial offer (+ trickled
candidates).   There's no reason to duplicate candidates in a subsequent
offer.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Nov 2015 07:43:49 +0000

Hi,

…

>4. (more for editors) 11.2.2 and 11.2.5 are exactly the same.  Why not just remove >11.2.5 and say 11.2.2 refers to all offers?

There was a mistake in 11.2.2. In the initial offer only unique addresses are used.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Nov 2015 07:58:29 +0000

Hi,

...

​>I thinking mandating the candidates be duplicated in the answer has three issues:
>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.

>>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."

>>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, 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.

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 16 Nov 2015 14:07:07 -0800

> Those are all fair points. I wish we'd had more implementation input when

That's what I'm providing now :).  We can still change the spec, can't we?
​

> ​>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.

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.​

> ​>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.​

> >>>>>> 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
> ​> 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.​
> ​

​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?​
​

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Nov 2015 22:58:26 +0000

Hi,

>> I thinking mandating the candidates be duplicated in the answer has three issues:
>>
​
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.
 
>>>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.​
​>>
>>   bundled "m=" line with a zero port value, within an offer.  Other
​> 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. 

>>>> 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.

>>>> 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.

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 16 Nov 2015 15:05:58 -0800

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

> 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.​
​

> ​>>Can you point out where in the draft it says that?  I tried finding it
> >> 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.
​

> ​>>> That sounds logical to me.  They aren't included in the first offer.
> >> 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
> Correct. We just need to make it very clear whether it applies only to
> candidate attributes, or to attributes with identical values in general.
>
> >>>> But, if we would do a change, we also need to look at the full
> picture, and consider subsequent offers etc.
> >>>
> >>> 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.​

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Nov 2015 19:22:29 +0000

Anyone else having an opinion on this?

Regards,

Christer

From: Peter Thatcher [mailto:[email-masked]]
Sent: 17 November 2015 01:06
To: Christer Holmberg <[email-masked]>
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,

​
Sure.

Ok.

That would work as well.
​

​>>>
​

​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, 19 Nov 2015 17:00:49 +0000

Folks,

We are talking about a rather big change here. So, if you have been involved in the BUNDLE work, it would be really good if you could indicate your opinion - even if you don't care whether we make the change or not...

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Christer Holmberg<mailto:[email-masked]>
Sent: ‎17/‎11/‎2015 11:22
To: Peter Thatcher<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Regards,

Christer

​
Sure.

Ok.

That would work as well.
​

​>>>
​

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 19 Nov 2015 20:08:43 -0800

“Optimize for the most often-used code path” should guide our thinking here.

Forcing duplication of ICE candidates on a BUNDLE/mux application just to ensure correctness of a legacy scenario does not represent a good engineering tradeoff. 

Today BUNDLE and RTP/RTCP mux represent the most popular mode of operation for WebRTC applications. 

If we are using BUNDLE and RTP/RTCP mux within ORTC (and now WebRTC 1.0, now that we have added RTCIceTransport objects), the BUNDLE’d m-lines represent a single RTCIceTransport object and there is only  a single component and a single set of ICE candidates.  

This is not to deny that there are legacy interop scenarios  where the Offerer needs to allocate ports RTP and RTCP on each m-line just in case the Answerer does not support BUNDLE and/or RTP/RTCP mux, and thus the Offerer needs to gather ICE candidates that would not be needed if BUNDLE/mux were negotiated.

The JS sample code for this is ugly, let alone the implementation code, all for a code path that will only be used a very small percentage of the time (which means that bugs may not get found/fixed).  

I’m not advocating that we make that legacy scenario impossible – just that we should not optimize for it.  For example, if we don’t duplicate ICE candidates and that turns out to be required, and another O/A exchange is needed to fix that, it wouldn’t bother me. 

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Tuesday, November 17, 2015 11:22 AM
To: Peter Thatcher <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Regards,

Christer

From: Peter Thatcher [mailto:[email-masked]] 
Sent: 17 November 2015 01:06
To: Christer Holmberg <[email-masked] <mailto:[email-masked]> >
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,

​
Sure.

​

Ok.

That would work as well.

​

​>>>
​

 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Nov 2015 07:20:38 +0000

Hi Bernard,

Thanks for your input!

Note, however, that in the initial offer you would still assign unique candidates for each non-bundle-only m- line. The suggestion is to remove the duplication requirement in the answer, and subsequent offers, where shared candidates are used.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Bernard Aboba<mailto:[email-masked]>
Sent: ‎20/‎11/‎2015 06:09
To: Christer Holmberg<mailto:[email-masked]>; 'Peter Thatcher'<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [MMUSIC] Questions about ICE candidates with BUNDLE

Regards,

Christer

To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>

​
Sure.

Ok.

That would work as well.
​

​>>>
​

Regards,

Christer