Subject: RE: [MMUSIC] Offer in a 200 (OK) and ICE

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Jan 2007 12:11:37 -0600

Use UPDATE if PRACK isn't supported.

I don't think we should allow an ICE SDP offer to occur on the 200 OK
because, quite honestly, I don't think anyone should be generating an
SDP offer on 200. It makes no sense... You've agreed to take a call that
you're not sure you're going to agree on the media for?

We have TCP, UPDATE, and PRACK. Since ICE is new, why not use these new
tools and depricate this obviously problematic offer/answer exchange for
ICE?

Is anyone out there really going to design something to send an SDP
offer on the 200 OK with ICE candidate addresses knowing that they may
wind up with a call failure or horrible clipping problems?

Regards,
Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 4:34 PM
> To: Christer Holmberg (JO/LMF)
> Cc: Miguel Garcia; Gonzalo Camarillo (JO/LMF); mmusic
> Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE
> 
> Well then, how *can* ICE work with an offerless INVITE or 
> reINVITE if PRACK is not used?
> 
> 	Paul
> 
> Christer Holmberg (JO/LMF) wrote:
> >>> But that would only work when both UAs support PRACK.
> >> Since ICE is new functionality anyway, would it be such a 
> burden to 
> >> require implementors of ICE to support PRACK?
> > 
> > Isn't that what I propsed when we discussed the 18x retransmission 
> > "hack" that ICE uses?
> > 
> > The message at that point was that it people did NOT want 
> to require 
> > PRACK in order to support ICE...
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> >> 	Paul
> >>
> >>> Gonzalo
> >>>
> >>> Paul Kyzivat wrote:
> >>>> When a UAS has received an offerless INVITE, and wants 
> to use ICE, 
> >>>> wouldn't it be better for it to return an offer in a 1xx
> >> rather than
> >>>> a 200, in order to sidestep this issue?
> >>>>
> >>>>         Paul
> >>>>
> >>>> Gonzalo Camarillo wrote:
> >>>>  > Hi,
> >>>>  >
> >>>>  >> With respect your proposal to delay the ACK with the
> >> SDP answer...
> >>>>  >> Isn't it so that delaying the ACK will generate
> >> retransmissions
> >>>> of  >> the 200 OK response? I think we need to be careful
> >> with this
> >>>>>> behavior. Is it possible to generate the ACK with the
> >> SDP answer,
> >>>>>> gather the candidate addresses, and then do a re-INVITE with an
> >>>> SDP  >> offer?
> >>>>  >
> >>>>  > the way it is usually specified (e.g., in 3pcc or session
> >>>> policies) is  > that we recommend to, in principle, 
> delay the ACK 
> >>>> because the operation  > that needs to be done between the
> >> 200 OK and
> >>>> the ACK usually completes  > very quickly. However,
> >> endpoints need to
> >>>> also be prepared for that  > operation not to complete so
> >> quickly. In
> >>>> such a case, the endpoint needs  > to send the ACK with 
> as good an 
> >>>> answer it can generate and UPDATE or  > re-INVITE at a
> >> later point,
> >>>> as you suggested.
> >>>>  >
> >>>>  > Cheers,
> >>>>  >
> >>>>  > Gonzalo
> >>>>  >
> >>>>  > _______________________________________________
> >>>>  > mmusic mailing list
> >>>>  > [email-masked]
> >>>>  > https://www1.ietf.org/mailman/listinfo/mmusic
> >>>>  >
> >>>>
> >> _______________________________________________
> >> mmusic mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/mmusic
> >>
> > 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Jan 2007 14:12:32 -0500

I just went back and reviewed this thread because its continued over a 
long time. It appears that everybody is pretty much agreeing on the 
general principles. Namely that if you are using ICE then you need to 
deliver the initial offer, with ICE, reliably *before* the 200.

I don't think UPDATE will work here, because I don't think it is 
appropriate to use UPDATE for the first offer, before any other offer 
has been sent in the invite dialog usage. (I guess this is debatable, 
but it isn't permitted according to the agreements codified in the 
offeranswer draft.)

If the UAC doesn't provide an offer and doesn't support PRACK then I 
think the UAS simply can't use ICE. If that means it must reject the 
call then so be it.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Jan 2007 14:58:49 -0600

Yeah, you're right, but I don't see why an INVITE with no SDP
effectively seems to constitute an offer.

I looked through the cases in RFC-3311 for the callee to send an UPDATE
and it's not allowed unless an OFFER/ANSWER exchange completed via a
reliable 18x/PRACK.

Can someone enlighten me as to why UPDATE isn't equally acceptable for
transporting an SDP offer as reliable 18x/PRACK?

Regards,
Brian

> Sent: Wednesday, January 03, 2007 1:13 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Christer Holmberg (JO/LMF); Miguel Garcia; Gonzalo 
> Camarillo (JO/LMF); mmusic
> I just went back and reviewed this thread because its 
> continued over a long time. It appears that everybody is 
> pretty much agreeing on the general principles. Namely that 
> if you are using ICE then you need to deliver the initial 
> offer, with ICE, reliably *before* the 200.
> 
> I don't think UPDATE will work here, because I don't think it 
> is appropriate to use UPDATE for the first offer, before any 
> other offer has been sent in the invite dialog usage. (I 
> guess this is debatable, but it isn't permitted according to 
> the agreements codified in the offeranswer draft.)
> 
> If the UAC doesn't provide an offer and doesn't support PRACK 
> then I think the UAS simply can't use ICE. If that means it 
> must reject the call then so be it.
> 
> 	Paul
> 
> Brian Stucker wrote:
> > SDP offer on 200. It makes no sense... You've agreed to take a call 
> > that you're not sure you're going to agree on the media for?
> > 
> > We have TCP, UPDATE, and PRACK. Since ICE is new, why not use these 
> > new tools and depricate this obviously problematic offer/answer 
> > exchange for ICE?
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Jan 2007 16:52:45 -0500

> deliver the initial offer, with ICE, reliably *before* the 200.

I think of that as a best practice, not as a requirement. In the same 
way a 'regular' ICE flow can have the answer in a 18x or 2xx, but 18x is 
the best practice.

ICE will work if the offer comes in the 2xx. The time required to 
perform the gathering steps (required prior to sending an ACK) is still 
relatively small compared to the retransmit intervals. I expect it would 
be completed well within 500ms, and thus there would be no spurious 
retransmits in most cases. The bigger problem is cases where the ACK is 
being delayed pending *human* interactions, since these are much slower. 
This is not such a case.

You do have the real drawback of ringing the phone prior to verifying 
connectivity with ICE, but as in the normal case, thats a best practice 
and not a requirement.

> think the UAS simply can't use ICE. If that means it must reject the 

No, I think it can use ICE - it just places the offer in the 2xx.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Jan 2007 16:00:42 -0600

I'm not worried about the spurious retransmissions, but the cruddy user
experience in general that slow-start frequently offers, which would be
exacerbated by the client doing any additional processing (in this case,
ICE) that is going to delay the response to the answer.

Then again, I just don't like the call flow at all in the first place,
ICE or not. I think ICE will work on a 200 OK SDP offer, but why would
you want to do it in the first place.

Yuck.

Brian 

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, January 03, 2007 3:53 PM
> To: Paul Kyzivat
> Cc: Stucker, Brian (RICH1:AR00); Miguel Garcia; mmusic; 
> Gonzalo Camarillo (JO/LMF); Christer Holmberg (JO/LMF)
> continued over a 
> I think of that as a best practice, not as a requirement. In 
> the same way a 'regular' ICE flow can have the answer in a 
> 18x or 2xx, but 18x is the best practice.
> 
> ICE will work if the offer comes in the 2xx. The time 
> required to perform the gathering steps (required prior to 
> sending an ACK) is still relatively small compared to the 
> retransmit intervals. I expect it would be completed well 
> within 500ms, and thus there would be no spurious retransmits 
> in most cases. The bigger problem is cases where the ACK is 
> You do have the real drawback of ringing the phone prior to 
> verifying connectivity with ICE, but as in the normal case, 
> thats a best practice and not a requirement.
> 
> 
> 
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Jan 2007 13:08:23 -0500

> effectively seems to constitute an offer.

It doesn't. I don't know what you mean here.

> and it's not allowed unless an OFFER/ANSWER exchange completed via a

Right.

> transporting an SDP offer as reliable 18x/PRACK?

Well, you really need the reliable 18x to establish a dialog. If you 
send the UPDATE prior to a 18x, then the UPDATE would establish the 
dialog. You would need to have it carry the record-route, and all kinds 
of awful things. A better alternative would be to have a 18x/PRACK 
without an offer/answer exchange, followed by an UPDATE from callee to 
caller at some point in time. I can't think of a reason that wouldn't 
work, except that RFC 3261 is pretty clear that the offer is supposed to 
come in the first reliable response. So, omitting one in the 18x would 
probably seriously confuse most implementations.

So, net/net is, I don't really see why we need to do anything new here. 
I think its fine for ICE to specify the two flows for offerless INVITE, 
one with the offer in a reliable 18x, and the other in a 2xx. The former 
will require PRACK, the latter worsens the user experience but will 
otherwise work.

-Jonathan R.

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 4 Jan 2007 12:12:16 -0600

I agree that it'll work. Just ugly.

Regards,
Brian 

> Sent: Thursday, January 04, 2007 12:08 PM
> Cc: Paul Kyzivat; Miguel Garcia; mmusic; Gonzalo Camarillo 
> (JO/LMF); Christer Holmberg (JO/LMF)
> > I looked through the cases in RFC-3311 for the callee to send an 
> > UPDATE and it's not allowed unless an OFFER/ANSWER exchange 
> completed 
> > via a reliable 18x/PRACK.
> 
> Right.
> 
> > 
> Well, you really need the reliable 18x to establish a dialog. 
> If you send the UPDATE prior to a 18x, then the UPDATE would 
> establish the dialog. You would need to have it carry the 
> record-route, and all kinds of awful things. A better 
> alternative would be to have a 18x/PRACK without an 
> offer/answer exchange, followed by an UPDATE from callee to 
> caller at some point in time. I can't think of a reason that 
> wouldn't work, except that RFC 3261 is pretty clear that the 
> offer is supposed to come in the first reliable response. So, 
> omitting one in the 18x would probably seriously confuse most 
> implementations.
> 
> I think its fine for ICE to specify the two flows for 
> offerless INVITE, one with the offer in a reliable 18x, and 
> the other in a 2xx. The former will require PRACK, the latter 
> worsens the user experience but will otherwise work.
> 
> -Jonathan R.
> 
> 
> 
> 
> --

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 5 Jan 2007 06:43:54 +0100

Hi, 

>Well, you really need the reliable 18x to establish a dialog. 

I don't want to argue against you on that, but I HAVE heard opinions
saying that you do not need a reliable response in order to establish a
dialog.

Also, chapter 12.1 of RFC3261 does say the following:

"Dialogs are created through the generation of non-failure responses
to requests with specific methods.  Within this specification, only
2xx and 101-199 responses with a To tag, where the request was
INVITE, will establish a dialog.  A dialog established by a non-final
response to a request is in the "early" state and it is called an
early dialog."

Note that the text only talks about non-failure responses (2xx and
101-199), not reliable responses (reliable provisional responses
(101-199) are not even defined in 3261).

>record-route, and all kinds of awful things.

Yes, and that is a good reason not to send UPDATE before you have sent a
reliable response - at least not by the called party. But, one could
claim that the early dialog may still be established before that.

>A better alternative would be to have a 18x/PRACK without an 

This is related to the discussion about the MUST to send an offer in the
first reliable 18x. It is listed as an issue in the offer/answer draft.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Jan 2007 09:52:25 -0500

Christer,

A non-reliable response *can* establish a dialog - *if* it is received 
by the UAC. In that case the UAC knows a dialog has been established, 
but the UAS does not.

So, if a UAC receives an unreliable provisional that contains a tag it 
could potentially then send an UPDATE within that dialog.

But when the UAS sends that unreliable provisional, since it doesn't 
know for sure that a dialog has been established, it can't yet send an 
UPDATE. If it did send one, and the provisional had been lost, then the 
UAC would not be able to associate the UPDATE with a dialog, and it 
would fail.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 7 Jan 2007 22:07:20 +0100

Hi, 

>A non-reliable response *can* establish a dialog - *if* it is 
>received by the UAC. In that case the UAC knows a dialog has 
>been established, but the UAS does not.

Yes.

>So, if a UAC receives an unreliable provisional that contains 
>a tag it could potentially then send an UPDATE within that dialog.

Yes.

But, that UPDATE can not contain a new SDP offer, since the previous
answer wasn't delivered reliably. 

One COULD claim that since the UAC has received the SDP (eventhough
unreliably) it should be allowed to send a new offer (the UAS could of
course not do that, since it doesn't know whether the answer reached the
UAC) since it does not know whether the. But as we know it is currently
not allowed.
 
>But when the UAS sends that unreliable provisional, since it 
>doesn't know for sure that a dialog has been established, it 
>can't yet send an UPDATE. If it did send one, and the 
>provisional had been lost, then the UAC would not be able to 
>associate the UPDATE with a dialog, and it would fail.

Yes.

One can receive a NOTIFY before receiving any response to a SUBSCRIBE,
though, so maybe it could be solved also for INVITE and UPDATE, but
let's not go there :)

Regards,

Christer

> >>> Can someone enlighten me as to why UPDATE isn't equally 
> acceptable 
> >>> for
> > 
> > saying that you do not need a reliable response in order to 
> establish 
> > a dialog.
> > 
> > 2xx and 101-199 responses with a To tag, where the request 
> was INVITE, 
> > will establish a dialog.  A dialog established by a 
> non-final response 
> > to a request is in the "early" state and it is called an early 
> > dialog."
> > 
> > Yes, and that is a good reason not to send UPDATE before 
> you have sent 
> > a reliable response - at least not by the called party. 
> But, one could 
> >> offer/answer exchange, followed by an UPDATE from callee 
> to caller at 
> >> some point in time. I can't think of a reason that wouldn't work, 
> >> except that RFC 3261 is pretty clear that the offer is supposed to 
> >> come in the first reliable response. So, omitting one in the 18x 
> >> would probably seriously confuse most implementations.
> > 
> > This is related to the discussion about the MUST to send an 
> offer in 
> > the first reliable 18x. It is listed as an issue in the 
> offer/answer draft.
> > 
> > Regards,
> > 
> > Christer
> > 
>