Draft: draft-ietf-sipping-service-examples-10.txt Reviewer: Dale R. Worley [worley@dworley.hsd1.ma.comcast.net] Review Date: Wednesday 6/21/2006 1:40 PM CST / Wednesday 6/28/2006 10:35 AM CST Review Deadline: 7/01/2006 Status: WGLC Sections: 2.16 (Call Park) and 2.17 (Call Pickup) Summary: ---------------------------------------------------------------------- ** General * Use of "Replaces" header There are a number of places where a "Replaces" header is illustrated. IMO, in all of these messages there should also be a "Require: replaces" header to ensure that if the UAC does not support INVITE-with-Replaces, it will reject the request with 420, rather than treating it as a request for a new dialog. (While working with a version of the sipX proxy, we discovered that sending INVITE-with-Replaces to a UA that does not support Replaces usually results in a poor user experience, and a failure of the initiating operation would have been preferable.) The uses of Replaces are: section 2.5, message F19 section 2.6, message F7 section 2.16, messages F9, F16 section 2.17, message F7 In addition, any REFER that instructs its recipient to construct an INVITE-with-Replaces should also instruct it to add "Require: replaces" to the INVITE. This appears in section 2.5, message F15 and section 2.16, message F5. I propose these messages should be revised to: section 2.5, message F15 F15 REFER Bob -> Alice REFER sips:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds2g Max-Forwards: 70 From: Bob ;tag=23431 To: Alice ;tag=1234567 Call-ID: 12345600@atlanta.example.com CSeq: 1025 REFER Refer-To: Referred-By: Contact: Content-Length: 0 section 2.16, message F5 F5 REFER Bob -> Park Server REFER sips:park@server.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Bob ;tag=02134 To: Park Server Call-ID: 4802029847@biloxi.example.com CSeq: 1 REFER Refer-To: Referred-By: Contact: Content-Length: 0 Similarly, section 2.6, message F5 is an IM that carries a SIP URI that will replace an existing dialog: F5 MESSAGE Bob -> Carol MESSAGE sips:carol@chicago.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnash Max-Forwards: 70 From: Bob ;tag=8675309 To: Carol Call-ID: sdjfdjfskdf@biloxi.example.com CSeq: 42 MESSAGE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE Supported: replaces Content-Type: text/html Content-Length: ... Do you want to take this call from Alice? * Authors' Addresses "alan@sisptation.com" s.b. "alan@sipstation.com" * Header line breaking While the grammar of RFC 3261 section 25.1 allows header values to be broken at most delimiters, it does not allow URIs to be broken. (And this is confirmed by the examples in RFC 3261.) So this header is invalid: Refer-To: and it must be written as: Refer-To: Note that "header parameters" on URIs can be broken, so this is valid: Contact: ;q=.01 Clearly, these long headers can't be represented directly in the I-D, so we need some sort of line-breaking convention. Perhaps something like this could be added to section 1.1: For publication, some headers must have line breaks inserted in locations that the grammar does not permit line breaks. A line that is presented here as ending with "<
>" should be interpreted by removing that string, the following line break, and any leading whitespace on the next line. The locations I've discovered that need this treatment would then be presented as follows: Section 2.5: F15 REFER Bob -> Alice REFER sips:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds2g Max-Forwards: 70 From: Bob ;tag=23431 To: Alice ;tag=1234567 Call-ID: 12345600@atlanta.example.com CSeq: 1025 REFER Refer-To: > sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3<
> %3Bfrom-tag%3D8675309> Referred-By: Contact: Content-Length: 0 Section 2.6: (This URI is not in a SIP header, but the HTML in the I-D causes NL-SP to appear twice in the value of the HREF attribute, and SIP URIs cannot contain NL or SP.) F5 MESSAGE Bob -> Carol MESSAGE sips:carol@chicago.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnash Max-Forwards: 70 From: Bob ;tag=8675309 To: Carol Call-ID: sdjfdjfskdf@biloxi.example.com CSeq: 42 MESSAGE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE Supported: replaces Content-Type: text/html Content-Length: ... Do you want to take this call from Alice? Section 2.16: F5 REFER Bob -> Park Server REFER sips:park@server.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Bob ;tag=02134 To: Park Server Call-ID: 4802029847@biloxi.example.com CSeq: 1 REFER Refer-To: > 12345601%40atlanta.example.com%3Bfrom-tag%3D314159<
> %3Bto-tag%3D1234567> Referred-By: Contact: Content-Length: 0 ** Section 2.16. Call Park * Call flow diagram The legend "ACK F18" is on page 147, but its arrow is on page 148. It would be an improvement if these could be on the same page. * Description IMO, the description of how Carol obtains the dialog identifiers of the call to retrieve is thin, because this issue is a significant hurdle for practical implementations. I would suggest rewriting the passage starting "Carol wishes to retrieve...", and extending it with a new paragraph: ... Carol wishes to retrieve the call, so she sends an INVITE containing the dialog identifiers to Alice, which replaces the session with the Park Server. Alice accepts the call and sends a BYE to the Park server. Note that Carol needs the dialog identifiers to carry out this sequence. This example assumes that Carol obtains them from Bob, who obtained them from a NOTIFY from the Park Server. If the Park Server did not return the dialog identifiers (Call-ID, To and From tags) in the NOTIFY, Carol could send a SUBSCRIBE to the Park Server to retrieve this information. "Note that this call is a special case ..." s.b. "Note that this call flow is a special case ...". * Spacing Message F7 has an extra blank line between the headers and body. Message F11 has an extra blank line between the title and the headers. * Comments The comments on messages F9 and F18 need ending periods. The comment on message F14 could be made clearer: /* Park Server reports success back to Bob by returning a 200 OK response. Bob obtains the dialog identifiers from the headers included in the response. */ ** Section 2.17. Call Pickup * Call flow diagram I would use the term "Two-way RTP established" rather than "Both way RTP Established", but "Both way" may be an established usage in SIP. "each others calls" s.b. "each other's calls". The sentence "Note that the order of the CANCEL/ACK sequence in F11 through F20 is not significant." needs work, not least that the messages involved are F9 through F12. Let me suggest: Note that the relative order of the 487/ACK sequence (F11/F12), and the CANCEL's 200 (F10) is not deterministic. * Spacing Message F8 has an extra blank line between the title and the headers. * Comments The comments on messages F3 and F8 need ending periods. The last sentence of the comment on message F19 would be better expressed "Later, Alice hangs up with Bob." * Dialog event package The dialog event package in F5 seems to use an obsolete schema. A correct version (with all the recommended elements) is: * The subscription The second NOTIFY, F14, shows "Subscription-State: active;expires=3600", just as does the first NOTIFY, F5. It would be more realistic to use, e.g., "expires=3598". F15 is a 481 response to the second NOTIFY. At first sight, this seems peculiar, as there is no sign that the subscription has vanished from Bill's memory. But it might be considered as more efficient way to terminate the subscription than having Bill send a terminating SUBSCRIBE, which would require Bob to send a final NOTIFY, which would together require two more SIP messages than the present scheme. But it would seem to be more natural to have the SUBSCRIBE specify "expires=0", since Bill does not need any more information after the first NOTIFY. To do that would require the following modifications: [Change to expires=0.] /* Bill decides to pick up the call */ F3 SUBSCRIBE Bill -> Bob SUBSCRIBE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc.biloxi.example.com:5061 ;branch=z9hG4bK74bf Max-Forwards: 70 From: Bill ;tag=8675309 To: Bob Call-ID: rt4353gs2egg@pc.biloxi.example.com CSeq: 1 SUBSCRIBE Contact: Event: dialog Subscription-State: active;expires=0 Accept: application/dialog-info+xml Content-Length: 0 [Change Subscription-State to terminated.] F5 NOTIFY Bob -> Bill NOTIFY sips:bill@pc.biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bK74br Max-Forwards: 70 From: Bob ;tag=31451098 To: Bill ;tag=8675309 Call-ID: rt4353gs2egg@pc.biloxi.example.com CSeq: 1 NOTIFY Contact: Event: dialog Subscription-State: terminated;reason=timeout Content-Type: application/dialog-info+xml Content-Length: ... [body] [Remove F14 and F15.] F14 NOTIFY Bob -> Bill F15 481 Dialog Does Not Exist Bill -> Bob [Renumber F16 and F17 to be F14 and F15.] -------------------------------------------------------------------------- Spurred by other reviewers, I reviewed the details of the example messages in sections 2.16 and 2.17. Section 2.16: * Is intended to be a GRUU? If so, to align it with draft-ietf-sip-gruu-09.txt, it should be replaced with . * The matter of using "Require: replaces" was discussed in my previous report. * Assuming that the user agents are at these hosts: Alice client.atlanta.example.com Bob client.biloxi.example.com Park Server server.example.com Carol client.chicago.example.com Then the Via's in these messages should contain the following hosts (and the received parameters in the responses should be adjusted accordingly): F1 client.atlanta.example.com F2 client.atlanta.example.com F3 client.atlanta.example.com F4 client.atlanta.example.com F7 server.example.com F8 server.example.com F10 server.example.com Missing received parameter. F11 server.example.com F12 client.atlanta.example.com -- also the method should be BYE, not ACK F13 client.atlanta.example.com F14 server.example.com The sipfrag in the body should have server.example.com in its Via. Also, the Via in the sipfrag is missing the branch and received parameters. (RFC 3420 requires that any headers included in a message/sipfrag be included in their entirety.) F15 server.example.com F16 client.chicago.example.com Also, the from-tag and to-tag parameters in the Replaces header are reversed. F17 client.chicago.example.com F18 client.chicago.example.com Section 2.17: * [ditto] Is intended to be a GRUU? If so, to align it with draft-ietf-sip-gruu-09.txt, it should be replaced with . * [ditto] The matter of using "Require: replaces" was discussed in my previous report. * Assuming that the user agents are at these hosts: Alice client.atlanta.example.com Bob client.biloxi.example.com Bill pc.biloxi.example.com Then the Via's in these messages should contain the following hosts (and the received parameters in the responses should be adjusted accordingly): F6 Missing received parameter. F7 The from-tag and to-tag parameters in the Replaces header are reversed. F12 client.atlanta.example.com F13 pc.biloxi.example.com F15 client.biloxi.example.com Missing received parameter. F16/F17 Should have a different branch parameter value than F3/F4