Draft: draft-ietf-sipping-service-examples-10.txt Reviewer: Elwell, John [john.elwell@siemens.com] Review Date: Friday 6/23/2006 5:30 AM CST Review Deadline: 7/01/2006 Status: WGLC Sections: 1, 2.3, 2.18, 2.19 Summary: ======== Section 1: "and will help further the goal of a standard implementation of RFC 3261 [2]". Add "... and some of its extensions". Section 1: "Other RFCs also comprise the SIP standard and are used and references in these call flows.". Change to "Other RFCs also form part of the SIP standard and are used and referenced in these call flows." Section 1: "Some examples make use the GRUU". Change to "Some examples make use of the GRUU". Section 1: "The use of Secure SIP URIs (sips) is shown throughout this document with assumed certificate validation for security. However, other security approaches such as Digest challenges can be used." I have a problem with this statement, since it seems to assume that SIPS and Digest challenges are mutually interchangeable. They are not, and the use of TLS transport in conjunction with Digest authentication is a likely scenario, particularly between a UA and its outbound proxy, where only TLS server authentication is likely to be available. I would propose "The use of Secure SIP URIs (sips) is shown throughout this document, implying TLS transport on each hop with assumed certificate validation. However, other security approaches can be used. Also the used of Digest authentication is shown in some examples." Section 2.3: "off of hold". Change to "off hold". Section 2.3: "Note that if Alice responds to the INVITE with hold SDP in the 200 OK, this call flow will not work properly.". I don't understand what this means. Greater explanation is required. In particular which INVITE (presumably F7), and what is meant by "hold SDP" here - a=inactive? Section 2.3 F1: "Call-ID: 12345600@atlanta.example.com". For global uniqueness, would "Call-ID: 12345600@client.atlanta.example.com" be better. This would impact the other flows too. Section 2.3 F1: "Contact: " and "c=IN IP4 music.server.example.com". I would normally expect the host part of the contact URI to be the same as the host in the SDP c= line, although of course it doesn't need to be. Section 2.3 F8: ";received=192.0.2.103". This is the same IP address as used by Bob in F2, for example. Likewise F14. Section 2.18 "A is alerted". Change to "Alice is alerted". Section 2.18 F2 "To: Bob ;tag=982039i4". A 486 response is not dialog-forming, so I am not sure why it contains a To tag. However, I can't find anything in RFC 3261 that clarifies this. If the To tag is removed, this will also impact F3. Section 2.18 F5: This is missing an Expires header. Section 2.18 F6 "NOTIFY sips:alice@atlanta.example.com SIP/2.0". Change to "NOTIFY sips:alice@atlanta.client.example.com SIP/2.0" Section 2.18 F6: This is missing a Contact header. Section 2.18 F8: "Subscription-State: active;expires=3600". The value of 3600 for the expires parameter is not very realistic - it has not decreased since the initial NOTIFY request. Section 2.18. It does not show Alice cancelling the subscription - not essential but likely. Section 2.18 F10: "o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com". The session ID and version are the same as in F1, but this is a new session request. Section 2.19 "Note that Bob's SIP phone immediately terminates the dialog by indicating in the NOTIFY (F3) that the subscription is terminated.". Although legitimate, this is not typical behaviour. Section 2.19 F1: "Call-ID: 12345601@atlanta.example.com". This is a curious choice of Call-ID, since the call is initiated by Bob@biloxy.com. This will impact subsequent flows too. Similar comment on F5. Section 2.19 F1: "Contact: ". Similarly this seems wrong. Presumably it should be the value in the Request-URI of F3. Section 2.19 F3: "Content-Type: message/sipfrag" - no body is shown, and I don't think there should be a body. Section 2.19 F4: ";received=192.0.2.113". This is the same as in F2 - should be different. Similar comment on F6/F7.