Subject: [Sip] Outbound-07 comments

From: "Kevin Johns" <[email-masked]>
Date: Fri, 19 Jan 2007 10:41:39 -0700

I did a read of Outbound-07 and have a few comments for consideration.
Overall this is a solid draft. 

Regards,

Kevin

Introduction,

First paragraph, Second to last sentence has a typo - Similarly there a
NAT could be present,... I think if you remove 'there' the sentence
would read correctly.

4.2. Initial Registrations

This section seems to cover both initial registration and
re-registration procedures. It might be helpful to break out the
re-registration requirements into a separate section.

4.4.2. Keepalive with STUN

Can you make the text normative? Specifically, if no other keepalive
mechanism is being used and the keepalive parameter is present in the
URI, the UA MUST periodically perform keepalive checks by sending STUN
binding requests...

5.3. Forwarding Requests

The second sentence states, 

"If the Edge Proxy receives a request where the edge proxy is the host
in the topmost Route header field value, and the Route header contains a
flow token, the proxy compares the flow in the flow token with the
source of the request. If these refer to the same flow, the Edge Proxy
removes the Route header and continues processing the request."

When would this ever occur? This seems to imply that the UA is
originating a dialog initiating request and inserts a route header with
a flow token which identifies the flow the UAC sent the request on.
There are no requirements in the draft indicating the UAC must do so,
further RFC 3327 does not indicate the UAC should include the Path
header received in the response to the REGISTER as a route header in a
dialog initiating response.

Additionally, This section talks about 'if the Edge Proxy determines the
Route header contains a flow token'. How does it determine this? I
assume based on the presence of the 'ob' parameter which was in the Path
header. If this is the case, it might be clearer to indicate if the
Route header contains the 'ob' parameter the Edge Proxy must do xyz...

6. Registrar Mechanisms: Processing REGISTER Requests

First paragraph, suggest restructuring to cover, no sip.instance,
sip.instance only, sip.instance with reg-id and reg-id only. Also, none
of this text is normative. Given it is updating the binding procedures
defined in RFC 3261 it might be useful to make this normative.

Sixth paragraph, why is the registrar required to store the reg-id if
the rules above are invoked and the registrar ignores this parameter?
While this is the simplest thing to do, it affects the re-registration
procedures as the registrar has to remember that it previously ignored
the reg-id and cannot use it to determine which contact to update on
re-registration. I think the intended operation is clear given the text
on initail registration (if the ob parameter in the first path header
entry is absent ignore the reg-id), but the one sentence on
re-registration (same paragraph) does not call out these rules.

Finally, there are no requirements on how the registrar manages the
contacts for a given AOR-instance-id combination. Would it be possible
to add a paragarph to cover registrar contact management in the case it
does not have a direct flow with the UAC?

9. Example Message Flow

The 200 OK responses to the REGISTER requests do not contain the Path
header. Given the UAC is required to support this and can optionally
inspect the value returned in the REGISTER response, its should be
included for completeness.

Message 8 - Why would the Edge Proxy record-route with a flow token?
This is a mid-dialog issue and given it is out of scope of outbound
should not be covered in the message flow, or indicated that the
secondary edge proxy may record-route and optionally include a flow
token with a disclaimer that this may affect mid-dialog failover
capabilities.

~~~~~~~~~~~~~~~~~~~~~~
Kevin C. Johns
Project Director - PacketCable Communications Protocols
CableLabs(r)
858 Coal Creek Circle
Louisville, CO 80027-9750
Phone:  303.661.9100
Direct: 303.661.3303
HTTP://www.CableLabs.com <http://www.cablelabs.com/>  

_______________________________________________
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