Hello, sorry for being with my comments. Please find one minor technical issue and several NITs below.
Minor Technical: 9. Example Message Flow The 200 OK on page 28 contains no Path header, which should carry the ob and/or the keepalive URI parameters to allow the UA to detect that Oubound is supported and used. How can the UA detect that outbound is supported and used for this flow when it receives a 200 OK like this one? In the case there is an edge proxy included which supports outbound the 200 OK should have the Path header with the parameters. If the edge proxy does not support outbound, the Path header should not have the parameters. If the edge proxy does not even support the Path extension, outbound can not be supported either. But how does the UA detect that the Registrar supports and uses outbound in case there is no edge proxy involved? The easiest and simple solution to me would be that the Registrar has to include a Path header into the reply which points to itself and carries the required parameters. Another alternative would be to rely only on the Suported/Required header and do not look at the Path URI at all. Then the keepalive algorithm would be implicitly determined by the used transport, but that would also mean that there is no way for the Registrar to let the UA know that it supports the optional TCP Keepalive algorithm. And the Supported/Required header would have to be included into the reply by edge proxy (in case), which is, I think, against the normal usage of these headers. NITs: 1. Introduction "This specification allows SIP registration when the UA is behind such a firewall or NAT." Proposed improvement: This specification ensures that the UA if it is behind such a firewall or NAT is reachable by the registrar after the first successful initial registration. 2.1 Definitions "outbound-proxy-set A set of SIP URIs...." Proposed improvement: outbound-proxy-set: A set of SIP URIs... 3.2 Single Registrar and UA " REGISTER sip:example.com;keep-crlf SIP/2.0 Via: SIP/2.0/TCP 192.0.2.1;branch... ... Contact: <sip:[EMAIL PROTECTED]>;reg-id=1;... " Why have Via and Contact different IPs? I assume this is a type and should look like this: REGISTER sip:example.com;keep-crlf SIP/2.0 Via: SIP/2.0/TCP 192.168.0.2;branch... ... Contact: <sip:[EMAIL PROTECTED]>;reg-id=1;... 3.3 Multiple Connections from a User Agent "..., so mechanism like SRV can be used..." Proposed improvement: ..., so mechanism like DNS SRV can be used... 4.1 Instance ID Creation "... as the device knows no other UUIDs were generated at this time." Proposed improvement: ... as the device knows no other UUIDs were generated at this time on this device. 4.2.1 Registration by Other Instances Is the second paragraph about unregister only ment for this particular case or for all UAs supporting this draft? To me it semms at it is ment for all UAs, as the star Contact should match all bindings anyway. Otherwise it should be explained somewhere what a star Contact with an instance-id and/or reg-id means. 4.4 Detecting Flow Failure The last paragraph talks about tags in the URIs of the outbound-proxy-set. Are these tags are still used after the Chicago meeting? If so, then there should be a refence to chapter 12. 5.4 Edge Proxy Keepalive Handling Why is TCP Keepalive not mentioned in this section? I think it should mention that this an optional keepalive mechanism for the edge proxy. 6. Registrar Mechanisms: Processing REGISTER Requests Last paragraph on page 22: "First the registrar examines the first Path header field value, if any." Proposed improvement: First the registrar examines the first (bottom most) Path header field value, if any. 4th paragraph on page 23: "Furthermore, the Registrar MUST NOR include this option-tag..." Fix: Furthermore, the Registrar MUST NOR include this option-tag... 8. STUN Keeplalive Processing 1st paragraph on page 26: "Typically, a SIP node first sends a SIP request and waits to receive a final response (other than a 408 response) over a flow to a new target destination, before sending any STUN messages." Why should an UA start sending any STUN messages when it received any non-2xx reply? I think the sentence above should be limited to 2xx responses only as indication that the flow is "established" and the UA can send STUN messages now. 12.2 SIP/SIPS URI Parameters Why is there no Parameter for the optional TCP Keepalive? Or should the sections talking about TCP Keepalive as an optional alternative be deleted from the document? Cheers Nils Ohlmeier _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
