Draft: draft-ietf-sipping-service-examples-10.txt Reviewer: Miguel Garcia [Miguel.An.Garcia@nokia.com] Review Date: Tuesday 6/27/2006 7:42 AM CST Review Deadline: 7/01/2006 Status: WGLC Sections: 2.14 and 2.15. Summary: ======== 1) About the call flow in Section 2.14: Alice receives the 403 in flow F8, including an Error-Info URI. I would assume that the INVITE F10 goes straight forward to that URI. However, flow F10 traverses once more the Proxy (proxy that wasn't initially traversed in flow F1). I don't think this is the natural behavior, why should Alice route the INVITE F10 via the proxy, once she got a URI that does not embed a Route header? Notice that the proxy is not Alice's outbound proxy, so I see no reason for this behavior. 2) The text under the flow in Section 2.14 refers to "user B". It should be "Bob" instead. 3) In all INVITE requests of both Sections 2.14 and 2.15 I am missing an Allow header. According to RFC 3261 Section 13.2.1, An Allow header field (Section 20.5) SHOULD be present in the INVITE. 4) In all the SDP bodies of both Sections 2.14 and 2.15, the "s=" line is populated as "s=Session SDP". RFC 3264 Section 5 recommends to set it to a white space or a dash for unicast streams: The SDP "s=" line conveys the subject of the session, which is reasonably defined for multicast, but ill defined for unicast. For unicast sessions, it is RECOMMENDED that it consist of a single space character (0x20) or a dash (-). Unfortunately, SDP does not allow the "s=" line to be empty. 5) In all the SDP bodies of both Sections 2.14 and 2.15 the "t=" line is populated with an initial time, such as "t=3034423619 0". According to RFC 3264 Section 5, it should be set to "t=0 0". The SDP "t=" line conveys the time of the session. Generally, streams for unicast sessions are created and destroyed through external signaling means, such as SIP. In that case, the "t=" line SHOULD have a value of "0 0". 6) Section 2.14, Flow F5. The Proxy-Authenticate header contains a "domain" directive set to "sips:ss1.example.com". However, RFC 2617 Section 3.2.1 suggest not to include the domain directive in the Proxy-Authenticate header: This directive is not meaningful in Proxy-Authenticate headers, for which the protection space is always the entire proxy; if present it should be ignored. 7) Same flow and header as in 6): I am missing a qop directive, perhaps set to "auth,auth-int". RFC 2617 Section 3.2.1. insists that the qop directive is optional just for backward compatibility issues only, so it should be present int eh Proxy-Authenticate header. This directive is optional, but is made so only for backward compatibility with RFC 2069 [6]; it SHOULD be used by all implementations compliant with this version of the Digest scheme. And also RFC 3261 in Section 22.4, bullet point 8 states the same: However, servers MUST always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values. If you accept this change, then the INVITE request in flow F7 has to add a qop="auth", a nc=00000001 and a cnonce (of your choice) to the Proxy-Authorization header to make the Digest authentication correct. 8) I noticed that flow F9 in Section 2.14 contains a Proxy-Authorization header. I think it is weird that the ACK request for a 403 response contains a Proxy-Authorization header. There is nothing the proxy can do with that group of credentials. The same applies to Flow F6 in Section 2.15. 9) Flow F12 in Section 2.14 uses "announce.example.com" as the hostname of the announcement server in the Contact header. However, the SDP in the same message and subsequent SIP message use "announcement.example.com", so they should be synchronized. 10) Flow F15 in Section 2.14 misses ".example" in the Request-URI, so it should be: sips:alice@client.atlanta.example.com 11) There are empty lines in the following flows: Section 2.14: F10, F16 Section 2.15: F4, F6 (double) 12) There is a bracket sign "[" right as the first line of Section 2.14, before the figure.