[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sipping] [Fwd: WGLC of draft-ietf-sipping-service-examples-10.txt]

To: sipping <sipping at ietf.org>
Subject: [Sipping] [Fwd: WGLC of draft-ietf-sipping-service-examples-10.txt]
From: worley at dworley.hsd1.ma.comcast.net (Dale R. Worley)
Date: Wed, 21 Jun 2006 14:39:41 -0400
List-help: <mailto:sipping-request@ietf.org?subject=help>
List-id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-post: <mailto:sipping@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
Following is my review of sections 2.16 (Call Park) and 2.17 (Call
Pickup) of draft-ietf-sipping-service-examples-10.txt.

Dale
----------------------------------------------------------------------
** 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 at client.atlanta.example.com SIP/2.0
      Via: SIP/2.0/TLS client.biloxi.example.com:5061
       ;branch=z9hG4bKnashds2g
      Max-Forwards: 70
      From: Bob <sips:bob at biloxi.example.com>;tag=23431
      To: Alice <sips:alice at atlanta.example.com>;tag=1234567
      Call-ID: 12345600 at atlanta.example.com
      CSeq: 1025 REFER
      Refer-To: <sips:39itp34klkd at chicago.example.com?Replaces=
       sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3
       %3Bfrom-tag%3D8675309&Require=replaces>
      Referred-By: <sips:bob at biloxi.example.com>
      Contact: <sips:bob at client.biloxi.example.com>
      Content-Length: 0

section 2.16, message F5

      F5 REFER Bob -> Park Server

      REFER sips:park at server.example.com SIP/2.0
      Via: SIP/2.0/TLS client.biloxi.example.com:5061
       ;branch=z9hG4bKnashds9
      Max-Forwards: 70
      From: Bob <sips:bob at biloxi.example.com>;tag=02134
      To: Park Server <sips:park at server.example.com>
      Call-ID: 4802029847 at biloxi.example.com
      CSeq: 1 REFER
      Refer-To: <sips:a8342043f at atlanta.example.com?Replaces=
       12345601%40atlanta.example.com%3Bfrom-tag%3D314159
       %3Bto-tag%3D1234567&Require=replaces>
      Referred-By: <sips:bob at biloxi.example.com>
      Contact: <sips:bob at client.biloxi.example.com>
      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 at chicago.example.com SIP/2.0
      Via: SIP/2.0/TLS client.biloxi.example.com:5061
       ;branch=z9hG4bKnash
      Max-Forwards: 70
      From: Bob <sips:bob at biloxi.example.com>;tag=8675309
      To: Carol <sips:carol at chicago.example.com>
      Call-ID: sdjfdjfskdf at biloxi.example.com
      CSeq: 42 MESSAGE
      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE
      Supported: replaces
      Content-Type: text/html
      Content-Length: ...

      <HTML>Do you want to take this call from
      <A HREF="sips:a8342043f at atlanta.example.com?Replaces=
       12345600 at atlanta.example.com%3Bto-tag%3D314159
       %3Bfrom-tag%3D1234567"&Require=replaces>
       Alice</A>? </HTML>

* Authors' Addresses

"alan at sisptation.com" s.b. "alan at 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: <sips:39itp34klkd at chicago.example.com?Replaces=
       sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3
       %3Bfrom-tag%3D8675309>

and it must be written as:

      Refer-To: <sips:39itp34klkd at chicago.example.com?Replaces=sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309>

Note that "header parameters" on URIs can be broken, so this is valid:

      Contact: <sip:foo at example.com>
               ;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 "<<br>>" 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 at client.atlanta.example.com SIP/2.0
      Via: SIP/2.0/TLS client.biloxi.example.com:5061
       ;branch=z9hG4bKnashds2g
      Max-Forwards: 70
      From: Bob <sips:bob at biloxi.example.com>;tag=23431
      To: Alice <sips:alice at atlanta.example.com>;tag=1234567
      Call-ID: 12345600 at atlanta.example.com
      CSeq: 1025 REFER
      Refer-To: <sips:39itp34klkd at chicago.example.com?Replaces=<<br>>
       sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3<<br>>
       %3Bfrom-tag%3D8675309>
      Referred-By: <sips:bob at biloxi.example.com>
      Contact: <sips:bob at client.biloxi.example.com>
      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 at chicago.example.com SIP/2.0
      Via: SIP/2.0/TLS client.biloxi.example.com:5061
       ;branch=z9hG4bKnash
      Max-Forwards: 70
      From: Bob <sips:bob at biloxi.example.com>;tag=8675309
      To: Carol <sips:carol at chicago.example.com>
      Call-ID: sdjfdjfskdf at biloxi.example.com
      CSeq: 42 MESSAGE
      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE
      Supported: replaces
      Content-Type: text/html
      Content-Length: ...

      <HTML>Do you want to take this call from
      <A HREF="sips:a8342043f at atlanta.example.com?Replaces=<<br>>
       12345600 at atlanta.example.com%3Bto-tag%3D314159<<br>>
       %3Bfrom-tag%3D1234567">
       Alice</A>? </HTML>

Section 2.16:

      F5 REFER Bob -> Park Server

      REFER sips:park at server.example.com SIP/2.0
      Via: SIP/2.0/TLS client.biloxi.example.com:5061
       ;branch=z9hG4bKnashds9
      Max-Forwards: 70
      From: Bob <sips:bob at biloxi.example.com>;tag=02134
      To: Park Server <sips:park at server.example.com>
      Call-ID: 4802029847 at biloxi.example.com
      CSeq: 1 REFER
      Refer-To: <sips:a8342043f at atlanta.example.com?Replaces=<<br>>
       12345601%40atlanta.example.com%3Bfrom-tag%3D314159<<br>>
       %3Bto-tag%3D1234567>
      Referred-By: <sips:bob at biloxi.example.com>
      Contact: <sips:bob at client.biloxi.example.com>
      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:

      <?xml version="1.0"?>
      <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
          version="0" state="full" entity="sips:bob at biloxi.example.com">
      <dialog id="94992014524" call-id="12345600 at atlanta.example.com"
          local-tag="3145678" remote-tag="1234567" direction="recipient">
        <duration>1</duration>
        <local>
          <identity display="Bob">sips:bob at biloxi.example.com</identity>
          <target>sips:bob at client.biloxi.example.com</target>
        </local>
        <remote>
          <identity display="Alice">sips:alice at atlanta.example.com</identity>
          <target>sips:a8342043 at atlanta.example.com</target>
        </remote>
        <state>early</state>
      </dialog>
      </dialog-info>

* 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 at biloxi.example.com SIP/2.0
      Via: SIP/2.0/TLS pc.biloxi.example.com:5061
       ;branch=z9hG4bK74bf
      Max-Forwards: 70
      From: Bill <sips:bill at biloxi.example.com>;tag=8675309
      To: Bob <sips:bob at biloxi.example.com>
      Call-ID: rt4353gs2egg at pc.biloxi.example.com
      CSeq: 1 SUBSCRIBE
      Contact: <sips:bill at pc.biloxi.example.com>
      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 at pc.biloxi.example.com SIP/2.0
      Via: SIP/2.0/TLS client.biloxi.example.com:5061
       ;branch=z9hG4bK74br
      Max-Forwards: 70
      From: Bob <sips:bob at biloxi.example.com>;tag=31451098
      To: Bill <sips:bill at biloxi.example.com>;tag=8675309
      Call-ID: rt4353gs2egg at pc.biloxi.example.com
      CSeq: 1 NOTIFY
      Contact: <sips:bob at client.biloxi.example.com>
      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.]

----------------------------------------------------------------------
[EOF]

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP
Prev by Date: [Sipping] I-D ACTION:draft-haluska-sipping-directory-assistance-00.txt
Next by Date: [Sipping] Updated I-D: draft-worley-sipping-pickup-02
Previous by thread: [Sipping] I-D ACTION:draft-haluska-sipping-directory-assistance-00.txt
Next by thread: [Sipping] Updated I-D: draft-worley-sipping-pickup-02
Index(es):
- Date
- Thread