Subject: Re: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues]

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 10:19:29 -0500

I think a SHOULD suffices in this case, not a MUST. MUST is something 
where it breaks if you don't do it.

-Jonathan R.

Christer Holmberg (JO/LMF) wrote:

> Hi, 
> 
> 
>>I'm OK with #2-#4 but I dont see the point of #1. Why?
> 
> 
> I was maybe a little unclear. What I meant was that if both the UAC AND
> the UAS support 100rel, they should use it, because if reliable
> transport of 18x is needed I think that the standardized 100rel
> mechanism should be used. 
> 
> I think that the STUN-acknowledgement mechanism should only be used if
> 100rel is not supported. Isn't that the reason the STUN-acknowledgement
> was defined in the first place - to allow UASs that do not support
> 100rel to still use ICE?
> 
> Regards,
> 
> Christer
> 
> 
> 
>>Christer Holmberg (JO/LMF) wrote:
>>
>>
>>>Hi,
>>>
>>>
>>>
>>>>>And, as I asked before, for how long would you keep 
>>
>>re-transmitting 
>>
>>>>>the 18x, if there is no STUN request coming to 
>>
>>"acknowledge" it (you 
>>
>>>>>cannot assume there will be a STUN request, e.g.
>>>
>>>in case
>>>
>>>
>>>>>there is some NAT/gate/GW in the path which will not pass it)? I 
>>>>>don't
>>>
>>>
>>>>>think we can use words as "send a few re-transmits", or 
>>
>>"re-transmit
>>
>>>for
>>>
>>>
>>>>>a while", in a standards specification.
>>>>
>>>>It doesn't say that. It says to use the retransmit intervals and 
>>>>timers as defined in RFC 3262, but that the retransmissions 
>>
>>stop when 
>>
>>>>you receive a STUN request or a PRACK (as opposed to just a 
>>
>>PRACK with 
>>
>>>>rfc3262).
>>>
>>>
>>>I think that also the following 3262 deviations should be clarified 
>>>(eventhough one may consider them obvious), in addition to the text 
>>>saying that this 18x can not be used for offer/answer purpose:
>>>
>>>1. If the UAC supports 100rel, the UAS MUST use it, and not use the 
>>>STUN request as acknowledgement. Ie the re-transmisson will 
>>
>>not cease 
>>
>>>if a STUN request is received before the PRACK.
>>>
>>>2. If 100rel is not used, and there is no STUN request before the 
>>>re-transmission timeout (64*T1), the UAS shall not reject 
>>
>>the INVITE 
>>
>>>just because the 18x "failed".
>>>
>>>3. The RFC3262 rule, saying that the first reliable 18x must be 
>>>acknowledged before futher reliable 18xs are sent, does not apply.
>>>
>>>4. When 200 OK is sent, the re-transmission of 18x (if 
>>
>>still ongoing) 
>>
>>>is ceased.
>>>
>>>Regards,
>>>
>>>Christer
>>>
>>
>>-- 
>>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
>>
> 
> 

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

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 1 Nov 2006 18:21:40 +0100

Hi, 

Ok.

But, still, if the UAC REQUIRES the usage of PRACK (Require: 100rel),
and the UAS supports it, the UAS MUST use it. If the UAS does not
support it, it MUST reject the INVITE.

Regards,

Christer

> > I was maybe a little unclear. What I meant was that if both the UAC 
> > AND the UAS support 100rel, they should use it, because if reliable 
> > 100rel is not supported. Isn't that the reason the 
> > STUN-acknowledgement was defined in the first place - to allow UASs 
> > that do not support 100rel to still use ICE?
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> >