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

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 06 Dec 2006 10:21:04 +0200

Hi,

a couple of small comments on the ICE spec. The spec should explicitly
talk about what to do when a user agent client receives an offer using
ICE in a 200 (OK). For example, the user agent client can delay the ACK
(with the answer) while gathering candidate addresses.

Message 9 in the example seems to arrive to the NAT even though it was
sent to the endpoint's private address. The figure gives the impression
that that message would be routed to the NAT and discarded there. The
figure may be clearer if the arrow does not reach any of the vertical
lines in the figure (i.e., the message is eventually dropped by the
routing infrastructure, not by the NAT).

Cheers,

Gonzalo

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

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 07 Dec 2006 09:29:35 +0200

> (with the answer) while gathering candidate addresses.

I do agree that the document ought to say something about an 
offer/answer in the 200/ACK. I think Section 13 is appropriate.

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?

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 07 Dec 2006 09:41:23 +0200

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Dec 2006 09:08:05 -0500

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 07 Dec 2006 16:18:35 +0200

But that would only work when both UAs support PRACK.

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Dec 2006 12:25:11 -0500

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

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 7 Dec 2006 21:29:59 +0100

>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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Dec 2006 17:34:16 -0500

Well then, how *can* ICE work with an offerless INVITE or reINVITE if 
PRACK is not used?

	Paul