Subject: [Sipping] Comments on BLA draft

From: "Dale Worley" <[email-masked]>
Date: Mon, 25 Jul 2005 18:25:35 -0400

Comments on "Implementing Bridged Line Appearances",
draft-anil-sipping-bla-02.txt.

I'm having some difficulty determining whether the draft is
overlooking some details, or whether these have been discussed
thoroughly in some other forum.  In any case, it would probably help
if the I-D was more explicit about some of the mechanisms it uses.

Overall presentation

1. There are important elements of the proposal that are "defined by
example" in section 6 alone, with no description in section 5.  This
seems to be a significant deficiency, as it makes it difficult to
envision all of the complications that might arise.  (I would be
willing to write some additions to section 5 if that would be useful.)

2. Throughout the examples, there is a habit of using a name
(particularly "Alice") to designate a Directory Address (AOR) with
BLA, a user agent with an appearance of the BLA, and the person who is
the primary operator of that UA.  While conflating the last two
meanings is not much of a problem, conflating them with the first
meaning makes the discussion more difficult to follow.  (E.g., it is
hard to say that "the INVITE to [DA] Alice is forwarded to [UA]
Alice.")  It would help if the DAs and the names of UAs/users were
drawn from different namespaces.

3. It seems to be the intention that in dialog event packages, the
<target> element of the <local> element conveys the value of the
Contact: header as sent by the UA (usually with an absolute IP address
as the host part of the URI), and the <identity> element of the
<local> element is intended to convey the AOR being used to establish
the dialog (the To: or From: header, as appropriate).  But the
examples generally do not provide a contact as the local-identity
element, but instead use an AOR in a local-target element,
contributing to the confusion I've described in (2).  (If a real UA
does this, it makes it difficult to use the local-target element as a
URI to contact the UA for call-control operations.)

4. Section 4.1 mentions a number of common ways to use BLA.  I think
it would help the reader to also say that these cases can all be
handled uniformly by the mechanisms being discussed.  Given the
confusion (2), it would help to remind the user that none of the
details of the cases in 4.1 are relevant to understanding the BLA
mechanism itself.

5. Section 8 makes much of reducing the expiration time for the
subscription from the State Agent to the UA.  But the expiration time
itself isn't important, what is important is that the State Agent
refresh the subscription frequently, which can be done without
reducing the specified expiration time in the SUBSCRIBE messages.
(Though reducing the expiration time might be a useful way to
accomplish this in some implementations.)

6. In the examples of outgoing calls, the Proxy does not perform any
integral function, and so the call flow could be simplified by
removing it.  (Assuming that we have the Proxy perform line assignment
for incoming calls, it cannot be removed from the incoming call
examples.)

Line IDs

7. Section 5.1 discusses the use of the "x-line-id" parameter.  We
should probably consider calling it "line-id" now that it will be
standardized.

8. The wording should be clarified to specify that the line-id is
relative to the DA.  Thus, a UA might use line-id's 0 and 1 for one
DA, and also have line-id's 0 and 1 for another DA.  (This being the
only way to make it possible for a UA to share some, but not all, of
its bridged DAs with other UAs.)

9. We probably want to specify that line-id's for a DA are
sequentially numbered 0, 1, 2, etc. up to whatever number of line
appearances are supported.  I expect that this is intended, but it
should be made explicit.

10. Section 5.1 discusses applying an x-line-id parameter to the
Alert-Info: header, but does not discuss what agent places it there,
or how it decides what value to use.

Protocol operations

11. Section 5 mentions the "sla" parameter of the event-name "dialog",
but does not directly mention its primary effect:  The subscription
from the State Agent to the User Agent that has "Event: dialog;sla"
tells the User Agent the contact point for making line reservations.

12. Section 6.2 says "shall send out a NOTIFY with event 'trying'".
But that is incorrect, and remarkably confusing to the reader, there
being no such event.  It should read "shall send out a dialog event
NOTIFY with state 'trying'".

13. Section 6.2 specifies that a successful vs. unsuccessful line
reservation request is to be indicated by the response code to the
NOTIFY.  This seems like it might be difficult to implement, as it
involves adding semantics to operations in the lower levels of the SIP
stack.

Instead, it seems like a UA could request a line reservation with a
simpler protocol that operates entirely at the application level:

    A.  Send a NOTIFY to the State Agent that includes a dialog in state
    "trying" for the requested line (which will be not in use in the
    latest NOTIFY received from the State Agent, otherwise the UA would
    not attempt to seize it).

    B.  Receive a 200 response as normal.  (This ensures that the sending
    of the response to the State Agent is reliable.)

    C.  Wait for the State Agent to send a NOTIFY which shows the line
    id in use.  The State Agent must of necessity return such a state
    change promptly, as the states reported to it for that line id
    have changed.

    D.  If the line id is shown in use by this UA (as evidenced by the
    local-target URI matching the Contact: URI used by this URI), the
    reservation was successful.

    E.  If the line is shown in use by another UA, the reservation was
    unsuccessful.

14. Section 6.3 shows a call incoming to a BLA group.  As far as I can
see, the proposal is that the UA that accepts the call is responsible
for reserving the line id on which to display the call.  But this
leads to race conditions.  For example:

    An incoming call is sent to UAs A and B.

    Users at UAs A and B accept the call simultaneously, both sending 200
    responses to the proxy.

    UA A attempts to reserve line id 2, the last available line id for
    this DA.

    UA B attempts to reserve line id 2 also.

    The proxy or caller chooses the 200 from UA B to accept, and sends
    a BYE to UA A.

    The State Agent accepts UA A's line reservation and rejects UA B's
    line reservation.

    UA A receives the BYE and terminates its dialog, sending a line free
    to the State Agent.

    UA B, receives the State Agent's rejection of its line reservation.

Requiring the UA to accept a call before reserving a line id makes it
impossible to reject a call with 486 if no line id is available -- the
UA may send a 200 response and only then discover that there is no
line id that it can reserve.

Also, forwarding an INVITE to the UAs before assigning a line id makes
it impossible to do one of the most common user BLA functions, namely
shouting across the office, "Alice, can you answer line 4?  It's Joe's
Towing.  I'll get line 5."

As far as I can see, the only way to make this situation work well is
for the proxy to obtain a line reservation from the State Agent, and
apply that information to the INVITEs it forwards to the UAs.  (This
seems to be implied in the paragraph about applying an x-line-id
parameter to the Alert-Info: header, but is not discussed anywhere.)

Interestingly, it seems that the proxy can obtain line reservations
from the State Agent in the same way that a UA does, by attempting to
publish a dialog event with state "trying" and seeing if the State
Agent incorporates that dialog into the combined dialog state.  This
communication can be done through (A) some non-SIP means, or (B)
through a provisioned relationship with the State Agent that operates
using a pair of subscriptions like those a UA would use, or (C) by
registering a dummy contact for the DA, thus causing the State Agent
to initiate a pair of subscriptions.  (The Proxy has to arrange to
recognize the dummy contact and never forward INVITEs to it, or for
the dummy contact to respond 501 to all INVITEs.)

Unlike a UA, the Proxy automatically selects the line id that it tries
to reserve, and should be intelligent enough that if its first
reservation attempt fails, it will attempt to seize a different line
id.

The critical difference between a Proxy's reservation and a UA's
reservation is that the Proxy may be dialog-stateless, and so have
difficulty ensuring that the reservation is released.  Assuming that
the Proxy does not want to maintain dialog state so that it can
send a NOTIFY to release its reservation when the incoming dialog
ends, it can use a policy of always releasing its reservations within
a few seconds -- any incoming dialog will have caused some UA to
progress to the ringing state within a few seconds, and so the UA will
maintain the line reservation even if the Proxy abandons it.

15. It would be helpful if the subscription structure were laid out in
more detail:

    A.  The State Agent sends a subscription to the Registrar for
    registration events for the DA <sip:[email-masked]>.

    B.  The User Agent sends a registration to the Registrar for the DA
    <sip:[email-masked]>.

    C.  The State Agent sends a subscription to the contact URI registered
    in B for dialogs involving that URI.

    D.  The User Agent sends a subscription to the Contact: URI from
    SUBSCRIBE C for dialogs involving the DA.  The User Agent knows the
    corresponding DA, because SUBSCRIBE C had as its request-URI the
    contact URI registered by the User Agent for the DA in step B.

    E.  For NOTIFYs sent for the subscriptions C and D, the BLA DA to
    which they apply is implied by the subscriptions they are for.

Similarly, when the UA receives an incoming call, it can discern the
appropriate DA based on the contact URI to which the INVITE was
directed, and the line id can be obtained from the Alert-Info: header.

>From this it is clear that as long as the UA registers distinct
contact URIs for distinct DAs, it can have BLA appearances for
multiple DAs, even if those DAs have the same user-names (of
necessity, in different domains), or if those DAs are in different
domains that are served by different State Agents.

16. Do we really want the proxy, when assigning incoming calls to line
id's, to use Alert-Info to carry the line id?  If so, we need to fix
some convention on how to represent an Alert-Info value that carries
line id information but nothing else.  This requires at least some
work, since according to RFC 3261, any Alert-Info value must contain a
URI.

17. There probably should be some detailed discussion of how the State
Agent consolidates state information from the UAs, an activity which
is more complex than it might first appear, and may require
maintaining state information that is not manifest in the outgoing
state event notifications.

For example, if a call rings on two UAs and both users answer it
simultaneously (only one winning the race), both UAs send to the State
Agent the sequence of states "early - committed - terminated".  (For
one UA, the committed phase is very short, only until the proxy or
caller sends a BYE to the "extra dialog".)  But when the first dialog
transitions to "terminated", the State Agent must remember that the
second dialog is still committed, and make sure that its consolidated
dialog state still shows the line id as being "committed" (though
perhaps with a different dialog than before), with no period of being
"terminated" in between.

Indeed, any states presented by different UAs for the same line id are
compatible, except that creating a dialog with "trying" state
(attempted line seizure) is incompatible with the existence of a
dialog in any state other than "terminated".

Wording

18. In section 5, item 1, the wording could be improved:  "for users
belonging to a BLA group" would better be "for contacts registered for
the BLA DA", and "all users registered to a BLA group" would better be
"all UAs registered for the BLA DA".

19. In section 5, item 5, it should read "for the state of all dialogs
involving the BLA contact URI", as there is no mechanism to subscribe
for the state of all dialogs at a UA (as far as I know).

Formatting matters

20. There are a considerable number of non-ASCII characters in the I-D.
Since this is by no means the first I-D I've seen that has this
problem, I wonder what typesetting program people are using that
produces non-ASCII characters.

21. The examples give many dialog event packages, which are in XML.
These would be more readable if they were indented according to the
logical structure of the XML.

22. There are a number of sections where blank lines do not appear
between paragraphs or items in a list, whereas inserting such blank
lines seems to be the standard format.

23. In a number of example messages, the typesetting program has broken
lines in a way that is not compatible with RFC 3261.

24. In section 6.1.1, message F5, the From: header seems to have an
unlikely value.  Wouldn't it be more likely to be "From:
<sip:[email-masked]>"?

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 26 Jul 2005 09:52:23 -0400

From: Venkatesh [mailto:[email-masked]]

> [VV]: Will take you up on the offer :-).

I'll put together a draft for your consideration.  Unfortunately this is a
busy week for me, and I can't do it before before next week.   Similarly, it
will be a while before I can reply to your other points.

Dale