Subject: [Sip] Comments on draft-ietf-sip-outbound-07

From: "Alfred E. Heggestad" <[email-masked]>
Date: Mon, 22 Jan 2007 09:27:22 +0100

Comments on draft-ietf-sip-outbound-07

 > 3.5.  Keepalive Technique
 >
 >    For connection-less transports, a flow definition could change
 >    because a NAT device in the network path reboots and the resulting
 >    public IP address or port mapping for the UA changes.  To detect
 >    this, requests are sent over the same flow that is being used for the
 >          ^^^^^^^^^^^^^^^^^

suggest renaming to "STUN Binding Requests are periodically sent ..."

 > 4.1.  Instance ID Creation
 >
 >   Each UA MUST have an Instance Identifier URN that uniquely identifies
 >
 >   ...
 >
 >   The UA SHOULD include a "sip.instance" media feature tag as a UA
 >

Why should the UA have a URN if it cannot use it in the signalling ?
Maybe change SHOULD to MUST ?

 > 4.4.  Detecting Flow Failure
 >
 >    The time between keepalive requests when using UDP-based transports
 >    SHOULD be a random number between 24 and 29 seconds while for TCP-
 >    based transports it SHOULD be a random number between 95 and 120
 >    seconds.

perhaps a silly questions, but should this interval change for each
keepalive request? I.e. should the UA re-calculate a new random value
for each keepalive request, or should it only calculate it once and
then re-use the same value for all subsequent keepalive requests.

in any case this is implementation specific but might be clarified.

 > 8.  STUN Keepalive Processing
 >

it seems to me that the logic of detecting if the SIP server supports
STUN multiplex is too complex and might lead to buggy implementations
or operational problems.

would it not be better for the client to check the Supported: sip-stun
option tag in the 200 OK response for the REGISTER message?

the behaviour of the SIP server can also change over time, i.e. moving
from old-style SIP server w/o STUN to support sip-stun, and vice versa.
the client will check the sip-stun option tag for each 200 OK and either
enable or disable STUN Binding Discovery.

General comments:

could we also include some example message flows between the Edge Proxy
and the registrar?

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 22 Jan 2007 14:17:31 -0600

Hi, Alfred,

> in any case this is implementation specific but might be clarified.

The reason we introduce these randomized delays is typically to prevent 
synchronization effects causing/resulting from high congestion.

It is certainly possible to re-caculate the random value for each keepalive 
request, but do people think this is necessary?

Thanks,

Spencer