Subject: Re: [MMUSIC] ICE Call setup latency

From: Jon Ringle <[email-masked]>
Date: Thu, 4 Nov 2004 17:48:10 -0500

Ping...

On Wednesday 27 October 2004 03:42 pm, Jon Ringle wrote:
> The -03 ICE draft in Figure 2, shows the Accept message occuring before the
> STUN checks are performed. I believe that this is because the STUN checks
> can't be performed until both the Initiator and Responder have created
> their connection tables. However the Accept message seems to imply that the
> user has accepted the call. The media won't flow until the after the
> connectivity checks has selected a usable transport address. This gives me
> concern in that normally when a user Accepts a call, the user speaks a
> greeting (ie. "Hello"). The greeting could be dropped because media from
> the Responder hasn't begun yet when it is spoken.
>
> Might I suggest that the Accept message shown as step (4) be replaced with
> a Provisional message (which for SIP could map to a 183 Early Media
> response). The connectivity checks could then be done before the user
> Accepts the call.
>
> Jon
>
> _______________________________________________
> 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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 08 Nov 2004 08:25:34 -0500

Sorry for the delay, Jon. Inline.

Jon Ringle wrote:

> STUN checks are performed. 

The responder can perform them immediately (i.e. 4 and 5 can happen in 
parallel). However, Message 4 has to arrive before message 5 can be 
successful. Obviously, message 6 has to happen after message 4.

> I believe that this is because the STUN checks 
> can't be performed until both the Initiator and Responder have created their 
> connection tables.

Right.

  However the Accept message seems to imply that the user
> has accepted the call. 

Accept corresponds to an answer as defined in RFC 3264. That doesn't 
have to come in a SIP 200 OK; it could come in a 183.

The media won't flow until the after the connectivity
> checks has selected a usable transport address. This gives me concern in that 
> normally when a user Accepts a call, the user speaks a greeting (ie. 
> "Hello"). The greeting could be dropped because media from the Responder 
> hasn't begun yet when it is spoken.

This is called post-pickup delay. If you do send the SDP answer in the 
200 OK, the post-pickup delay is increased by a STUN RTT. That is, after 
the 200 OK, it has to wait for a STUN request and response before it can 
send media. Those RTT are e2e, unlike the signaling. Thus, it is not too 
bad.

Sending the SDP in the 183 would make the post-pickup delay zero.

> 
> Might I suggest that the Accept message shown as step (4) be replaced with a 
> Provisional message (which for SIP could map to a 183 Early Media response). 
> The connectivity checks could then be done before the user Accepts the call.

What needs to change is that the section on mapping ICE into SIP/SDP has 
to clarify that the answer can come in a 18x, and that doing so is a 
good idea from a post-pickup perspective. I'll make that change.

Thanks,
Jonathan R.

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