Subject: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 25 Mar 2011 14:12:53 +0100

Hi all,

please find the slides we want to present at the MMUSIC session at
http://www.ietf.org/proceedings/80/slides/mmusic-2.ppt

The draft mentions two cases of bad interactions caused by the ICE updated offer
http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-00

We want to get input on the following topics:
Any other suggestions in addition to the already proposed work-arounds?
Do we really need the ICE updated offer
- How many middleboxes work well with the updated offer but would not work without it?
- Or putting it another way, how many middleboxes would still fail with the updated offer (e.g., rejecting it)?
- updated offer is only SHOULD for cap-neg, so why MUST for ICE?

Christer Holmberg and Peter Musgrave have already shared some thoughts.
Are there further opinions in the group?

Thanks and Kind Regards
Thomas

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 25 Mar 2011 11:03:02 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stach, Thomas
> Sent: Friday, March 25, 2011 6:13 AM
> To: [email-masked]
> Subject: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer
> 
> Hi all,
> 

Sorry if this idea has been discussed already, but ...

... Could we ask the middlebox to add a "Please-send-updated-offer:" 
header to the SIP message, if it wants to see an updated offer??  That means
it doesn't need to understand ICE, but rather just needs to add that
header.  It's still "a change to the middlebox", true, but it's a really
minor change compared to understanding ICE.

-d

> Thanks and Kind Regards
> Thomas
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Stach, Thomas" <[email-masked]>
Date: Sun, 27 Mar 2011 15:10:48 +0200

See inline

> -----Ursprüngliche Nachricht-----
> Von: Dan Wing [mailto:[email-masked]] 
> Gesendet: Freitag, 25. März 2011 19:03
> An: Stach, Thomas; [email-masked]
> Betreff: RE: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer
> 
> > - How many middleboxes work well with the updated offer but 
> would not
> > work without it?
> > - Or putting it another way, how many middleboxes would 
> still fail with
> > the updated offer (e.g., rejecting it)?
This is certainly an option if we want to do something.
However, I don't think we're there yet.
At this point in time, we try to focus on collecting knowledge how middleboxes react in real life.
Do they really break without the updated offer? 
 - E.g, they should have already passed onwards STUN checks before a non-default candidate could be selected.
Or did somebody see a failure because of the updated offer?

Any input in that directions would be very valuable in finding out if there's interest/need for more work.

Regards
Thomas

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Mar 2011 11:34:18 +0200

> From: Stach, Thomas [mailto:[email-masked]]
> Sent: Sunday, March 27, 2011 3:11 PM
> To: Dan Wing; [email-masked]
> Subject: AW: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer
> 
> See inline
> 

The ones that are believed to break are in PacketCable.  In 
Packetcable's architecture (and deployments) additional 
timeslots are provided to a user's cablemodem for RTP flow
associated with a phone call, and those timeslots are
removed at the end of the phone call.

-d

> > =

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 29 Mar 2011 19:50:03 -0400

> minor change compared to understanding ICE.

I assume by "middlebox", we're talking about the 3PCC-style B2BUA scenario in the slides?  (which looks like a click-to-call app)  In that scenario, the B2BUA is *not* a media-relaying middlebox, right?

[set_worldview="utopian"]

Regardless, istm the 3PCC B2BUA needs to do the right thing, which is to be a SIP B2BUA.  As the UAS, it should either queue or answer the UPDATE from UA1, and internally save the SDP and generate its own UPDATE as a UAC to UA2.

This problem isn't specific to ICE - UA1 could send an UPDATE anytime (or re-INVITE at any time after the ACK), and the 3PCC system needs to be able to handle it somehow.  And if it can't, then it shouldn't indicate it can support UPDATE in its Allow header.

Also, I believe Flow-I of rfc3725, which is what the slide references, would not have the B2BUA sending that ACK until it gets the 200 from UA2 (with nasty repercussions for delaying the ACK, of course).

[set_worldview="normal"]

-hadriel

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 30 Mar 2011 12:51:05 +0200

Hadriel,

see inline

> Von: Hadriel Kaplan [mailto:[email-masked]] 
> Gesendet: Mittwoch, 30. März 2011 01:50
> An: Dan Wing
> Cc: Stach, Thomas; [email-masked]
> Betreff: Re: [MMUSIC] Presentation of Draft-elwell-ice-updated-offer
> 
> 
> I assume by "middlebox", we're talking about the 3PCC-style 
> B2BUA scenario in the slides?  (which looks like a 
> click-to-call app)  In that scenario, the B2BUA is *not* a 
> media-relaying middlebox, right?
> 
> Regardless, istm the 3PCC B2BUA needs to do the right thing, 
> which is to be a SIP B2BUA.  As the UAS, it should either 
> queue or answer the UPDATE from UA1, and internally save the 
> SDP and generate its own UPDATE as a UAC to UA2.
> 
> This problem isn't specific to ICE - UA1 could send an UPDATE 
> anytime (or re-INVITE at any time after the ACK), and the 
> 3PCC system needs to be able to handle it somehow.  
Well, this problem is specific to ICE since ICE wants us to provide the answer early in order to get the STUN checks going.

> And if it 
> can't, then it shouldn't indicate it can support UPDATE in 
> its Allow header.
Just replace the UPDATE with a re-INVITE and you're in the same mess.

> 
> Also, I believe Flow-I of rfc3725, which is what the slide 
> references, would not have the B2BUA sending that ACK until 
> it gets the 200 from UA2 (with nasty repercussions for 
> delaying the ACK, of course).
Yes, but again ICE wants to have the answer early
Regards
Thomas

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 30 Mar 2011 07:37:09 -0400

> Well, this problem is specific to ICE since ICE wants us to provide the answer early in order to get the STUN checks going.

Sorry, I wasn't clear - I don't mean it's not a problem that needs to be solved - but rather the problem and thus solution are not ICE-specific.  ICE may happen to exacerbate it, but 3PCC systems need to handle these cases regardless of ICE.  No?

> Just replace the UPDATE with a re-INVITE and you're in the same mess.

Not technically - the Flow-I case in rfc3725 does not send the ACK back until UA2 returns 200, so there is no opportunity for a re-INVITE SDP overlap. (I realize that in the slides the ACK is not being delayed, but the slide says it's Flow-I of rfc3725)  

But anyway that wasn't my point - my point was if you're a 3PCC B2BUA doing click-to-call, it does not absolve you of needing to be a SIP B2BUA.  If you say it's a problem of UPDATE handling, then the B2BUA should not indicate it can handle UPDATEs.  If you say it's still a problem for re-INVITE, then the B2BUA should not claim it supports RFC 3261.

BTW, I realize the real world may be different, which is why I wrapped my comments in worldview="utopian" tags. ;)
Is it the case that the 3PCC B2BUA cannot reasonably handle this as the logical concatenation of UAS+UAC in the real world? If so, why not?

-hadriel

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 30 Mar 2011 14:22:20 +0200

> Gesendet: Mittwoch, 30. März 2011 13:37
> An: Stach, Thomas
> Cc: Dan Wing; [email-masked]
> Betreff: Re: AW: [MMUSIC] Presentation of 
> Draft-elwell-ice-updated-offer
> 
> 
> > Well, this problem is specific to ICE since ICE wants us to 
> provide the answer early in order to get the STUN checks going.
> 
> Sorry, I wasn't clear - I don't mean it's not a problem that 
> needs to be solved - but rather the problem and thus solution 
> are not ICE-specific.  ICE may happen to exacerbate it, but 
> 3PCC systems need to handle these cases regardless of ICE.  No?
Sure, I think we are on the same page. 
Of course this 3PCC problem can be solved. 
Slide 6 mention 100rel and UPDATE, but they raise the bar for deployment of ICE, especially 
if you want ICE just for IPv4/IPv6 transition.
The discussed draft just explores 2 problems that arise during ICE deployment
and asks if there is interest to do something about it without yet proposing solutions.

Regards
Thomas

> Not technically - the Flow-I case in rfc3725 does not send 
> the ACK back until UA2 returns 200, so there is no 
> opportunity for a re-INVITE SDP overlap. (I realize that in 
> the slides the ACK is not being delayed, but the slide says 
> it's Flow-I of rfc3725)  
> 
> But anyway that wasn't my point - my point was if you're a 
> 3PCC B2BUA doing click-to-call, it does not absolve you of 
> needing to be a SIP B2BUA.  If you say it's a problem of 
> UPDATE handling, then the B2BUA should not indicate it can 
> handle UPDATEs.  If you say it's still a problem for 
> re-INVITE, then the B2BUA should not claim it supports RFC 3261.
> 
> BTW, I realize the real world may be different, which is why 
> I wrapped my comments in worldview="utopian" tags. ;)
> Is it the case that the 3PCC B2BUA cannot reasonably handle 
> this as the logical concatenation of UAS+UAC in the real 
> world? If so, why not?
> 
> -hadriel
> 
>

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 30 Mar 2011 14:53:51 +0200

replying to myself inline 

> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Stach, Thomas
> Gesendet: Mittwoch, 30. März 2011 14:22
> An: Hadriel Kaplan
> Cc: [email-masked]
Well, 
"...eliminating the need for the updated offer-answer cycle"
mentions a possible solution.

Thomas