Subject: Re: [Sip] Outbound-07 comments

From: Cullen Jennings <[email-masked]>
Date: Sun, 4 Mar 2007 10:18:14 -0800

Many thanks - good comments - fixed the easy one and unfortunately  
did not fix the one hard one on restructuring stuff to make things  
clearer

On Jan 19, 2007, at 9:41 AM, Kevin Johns wrote:

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

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

fixed to cover both in this 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…

fixed

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

This happens when an incoming INVITE goes to the phone that  
registered using outbound - the home proxy will look up the flow  
token in the registration and insert that when it sends it to the  
edge proxy.

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

It tries to decode it using the Algorithm 1 or 2 (or some algorithm  
it uses) and if it works and the proxy believes it is a flow token it  
created then it uses it.

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

This might be better - I just can't bring myself to get the energy to  
rewrite this now. If you think this is critical, bug on the next  
version to fix it.

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

think I agree but I did not change text

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

on this one - I'm lost on what cases it is that needs to be covered  
but I think the meta point is restructureing this text to cover all  
the cases would make it better.

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

Hmm - the path header would be empty so is the right thing no header  
or a header that just says "Path:" with no header field values. The  
syntax of the path header indicates that it is not allowed to be empty.

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

Well it needs to do something to make sure that when future messages  
arrive, they have the flow token in them so that the edge proxy knows  
what flow to forward them over.

>
> ~~~~~~~~~~~~~~~~~~~~~~
> Kevin C. Johns
> Project Director - PacketCable Communications Protocols
> CableLabs®
> 858 Coal Creek Circle
> Louisville, CO 80027-9750
> Phone:  303.661.9100
> Direct: 303.661.3303
> 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

_______________________________________________
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