9. Interoperability with Non-shared Appearance UAs
It is desirable to allow a basic UA that does not directly support
shared appearance to be part of a shared appearance group. To
support this, the Proxy must collaborate with the Appearance Agent.
This is not required in the basic shared appearance architecture;
consequently, shared appearance interoperability with non-shared
appearance UAs will not be available in all shared appearance
deployments.
First, a UA that does not support dialog events or the shared
appearances feature will be discussed. Then, a UA that does support
dialog events but not the shared appearances feature will be
discussed.
9.1. Appearance Assignment
A UA that has no knowledge of appearances will only have appearance
numbers for outgoing calls if assigned by the Appearance Agent. If
the non-shared appearance UA does not support Join or Replaces, all
dialogs SHOULD be marked "exclusive" to indicate that these options
are not available. Marking these dialogs "exclusive" provides a
better user experience and avoids extra SIP messaging failures.
9.2. Appearance Release
In all cases, the Appearance Agent must be aware of the dialog
lifetime to release appearances back into the group.
It is also desirable that any dialog state changes (such as hold,
etc.) be made available to other UAs in the group through the Dialog
Event Package. If the Appearance Agent includes a proxy that Record-
Routes for dialogs from the non-shared-appearance-aware UA, the
Appearance Agent will know about the state of dialogs including hold,
etc. This information could be determined from inspection of non-
end-to-end-encrypted INVITE and re-INVITE messages and added to the
dialog information conveyed to other UAs.
9.3. UAs Supporting Dialog Events but Not Shared Appearance
Interoperability with UAs that support dialog events but not the
shared appearances feature is more straightforward. As before, all
appearance number assignments must be done by the Appearance Agent.
The Appearance Agent SHOULD still include appearance information in
NOTIFYs -- this UA will simply ignore this extra information. This
type of UA will also ignore appearance number limitations and may
attempt to join or replace dialogs marked exclusive. As a result,
the Proxy or UAs need to reject such requests or the dialogs will be
joined or taken.
10. Provisioning Considerations
UAs can automatically discover if this feature is active for an AOR
by looking for the 'shared' Event header field parameter in a
response to a dialog package SUBSCRIBE to the AOR, so no provisioning
for this is needed.
The registrar will need to be provisioned to accept either first or
third party registrations for the shared AOR. First party
registration means the To and From URIs in the REGISTER request are
the shared AOR URI. Third-party registration means the To URI is the
shared AOR URI and the From URI is a different AOR, perhaps that of
the individual user. Either the credentials of the shared AOR or the
user MUST be accepted by the registrar and the Appearance Agent,
depending on the authorization policy in place for the domain.
If the Appearance Agent needs to subscribe to the dialog state of the
UAs, then the Appearance Agent and the UAs need to be provisioned
with credentials so the UAs can authenticate the Appearance Agent.
In some cases, UAs in the shared appearance group might have a UI
limitation on the number of appearances that can be rendered.
Typically, this will be hard-phones with buttons/lamps instead of
more flexible UIs. In this case, it can be useful for the Appearance
Agent to know this maximum number. This can allow the Appearance
Agent to apply policy when this limit is reached, e.g., deny a call.
However, this mechanism does not provide any way to discover this by
protocol means.
11. Example Message Flows
The next section shows call flow and message examples. The flows and
descriptions are non-normative. Note that, in these examples, all
INVITEs sent by a UA in the group will be From the shared AOR
(sip:HelpDesk@example.com in this case), and all INVITES sent to the
group will have a Request-URI of the shared AOR. Any other requests
would not apply to this feature and would be handled using normal SIP
mechanisms.
Note that the first 12 examples assume the Appearance Agent is aware
of dialog state events. The example in Section 11.13 shows the case
where this is not the case, and, as a result, the Appearance Agent
initiates a subscription to users of the shared AOR. Any of the
other call flow examples could have shown this mode of operation as
it is equally valid.
11.1. Registration and Subscription
Bob and Alice are in a shared appearance group identified by the
shared appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using
contact sip:bob@ua2.example.com. Alice REGISTERs with contact
sip:alice@ua1.example.com.
UAs for Alice and Bob subscribe to the dialog package for the
appearance AOR and publish dialog state to the Appearance Agent.
Message exchanges between the Registrar, Appearance Agent, Alice, and
Bob are shown below. The call flow examples below do not show the
authentication of subscriptions, publications, and notifications. It
should be noted that for security purposes, all publications and
subscriptions must be authorized before they are accepted.
Also note that registrations and subscriptions must all be refreshed
by Alice at intervals determined by the expiration intervals returned
by the Registrar or Appearance Agent.
Registrar Appearance Agent Alice Bob
| | | |
| | | |
|<--------------------------- REGISTER F1<| |
| | | |
Contact: <sip:alice@ua1.example.com>;expires=3200
Contact: <sip:bob@ua2.example.com>;expires=3600
Content-Length: 0
11.2. Appearance Selection for Incoming Call
In the call flow below, Bob and Alice are in a shared appearance
group. Carol places a call to the shared appearance group AOR. The
Appearance Agent sends NOTIFYs to Alice and Bob telling them what
appearance the call is using. Both Alice and Bob's devices are
alerted of the incoming call. Bob answers the call.
Note that it is possible that both Alice and Bob answer the call and
send 200 (OK) responses to Carol. It is up to Carol to resolve this
situation. Typically, Carol will send ACKs to both 200 OKs but send
a BYE to terminate one of the dialogs. As a result, either Alice or
Bob will receive the BYE and publish that their dialog is over.
However, if Carol answers both Alice and Bob and keeps both dialogs
active, then the Appearance Agent will need to resolve the situation
by moving either Alice or Bob's dialog to a different appearance.
All NOTIFY messages in the call flow below carry dialog events and
only dialog states are mentioned for simplicity. For brevity, the
details of some messages are not shown below. Note that the order of
F2 - F5 and F7 - F8 could be reversed.
Forking Appearance
Carol Proxy Agent Alice Bob
| | | | |
|>F1 INVITE >| | | |
| |< - - - - - >| | |
| | |>F2 NOTIFY ----------->|
| | | | |
| | |<F3 200 OK -----------<|
| | | | |
| | |>F4 NOTIFY ->| |
| | | | |
| | |<-200 OK F5-<| |
|<- 100 F6 -<| | | |
| |>F7 INVITE (appearance=1) ---------->|
| | | | |
| |>F8 INVITE (appearance=1) >| |
| | | | |
| |<-------------------- Ringing 180 F9<|
|< 180 F10 -<| | | |
To: <sip:alice@example.com>;tag=18433323-C3D237CE
Call-ID: 1e361d2f-a9f51109-bafe31d4
CSeq: 13 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active;expires=2500
Contact: <sip:appearanceagent.example.com>
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="17"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345"
remote-tag="44BAD75D-E3128D42"
local-tag="7349dsfjkFD03s"
direction="recipient">
<sa:appearance>1</sa:appearance>
<state>confirmed</state>
<local>
<target>sip:bob@ua2.example.com</target>
</local>
<remote>
<identity>sip:carol@ua.example.com</identity>
</remote>
</dialog>
</dialog-info>
11.3. Outgoing Call without Appearance Seizure
In this scenario, Bob's UA places a call without first selecting/
seizing an appearance number. After Bob sends the INVITE, the
appearance assigns an appearance number for it and notifies both
Alice and Bob.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
| |<------------------------------------- INVITE F1<|
| | | | |
| |>F2 100 Trying --------------------------------->|
</local>
</dialog>
</dialog-info>
F6 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=497585728578386
To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a
CSeq: 7 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com
;branch=z9hG4bK1711759878512309
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active;expires=2000
Contact: <sip:appearanceagent.example.com>
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="78"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="02538339hfgdf3ce597f9e3egkl3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
11.4. Outgoing Call with Appearance Seizure
In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) selecting/seizing an appearance number before sending
the INVITE. After receiving the 200 (OK) from the Appearance Agent
confirming the appearance number, Bob's UA sends the INVITE to Carol
and establishes a session. For brevity, details of some of the
messages are not included in the message flows. Bob's UA puts as
| | | | |
| | |>F23 200 OK ->| |
| | | |------ NOTIFY F24>|
| | | | |
| | | |<F25 200 OK -----<|
| | | | |
Figure 4. Outgoing Call with Appearance Seizure Example
F1 to F4: Bob uses the shared appearance of the Help Desk on his UA
to place an outgoing call (e.g., he goes off-hook). Before sending
the outgoing INVITE request, Bob publishes to the Appearance Agent
reserving appearance number 1. The Appearance Agent notifies Alice
(and all other UAs, including Bob) of the event by sending NOTIFYs.
F1 Bob ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:HelpDesk@example.com>
CSeq: 7 PUBLISH
Call-ID: 44fwF144-F12893K38424
Contact: <sip:bob@ua2.example.com>
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
<remote>
<identity uri="sip:carol@example.com">
</identity>
</remote>
</dialog>
</dialog-info>
11.5. Outgoing Call without Using an Appearance Number
In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) indicating that he does not want to utilize an
appearance number for this dialog. The PUBLISH does not have an
appearance element but does have the 'shared' Event header field
parameter. As a result, the Appearance Agent knows the UA does not
wish to use an appearance number for this call. If the Appearance
Agent does not wish to allow this, it would reject the PUBLISH with a
400 (Bad Request) response and the UA would know to re-PUBLISH
selecting/seizing an appearance number.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| | |<-- NOTIFY F3<| |
| | | | |
| | |>F4 200 OK -->| |
| | | |------- NOTIFY F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F7<|
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator">
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
Note that F7 would be the same as the previous example.
11.6. Appearance Release
Bob and Carol are in a dialog, created, for example as in
Section 11.3. Carol sends a BYE to Bob to terminate the dialog and
the Appearance Agent de-allocates the appearance number used, sending
notifications out to the UAs in the shared group.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
|>F22 BYE ---->| | | |
| |>F23 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ 200 OK F24<|
|<--200 OK F25<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F26<| |
| | | | |
| | |>F27 200 OK ->| |
| | | |------ NOTIFY F28>|
| | | | |
| | | |<F29 200 OK -----<|
Figure 6. Appearance Release Example
F28 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=497585728578386
To: <sip:bob@example.com>
Call-ID: a7d559db-d6d7dcad-311c9e3a
CSeq: 7 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com
;branch=z9hG4bK759878512309
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active;expires=1800
Contact: <sip:appearanceagent.example.com>
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>terminated</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
11.7. Appearance Pickup
In this scenario, Bob has an established dialog with Carol created
using the call flows of Figures 1 or 2. Bob then places Carol on
hold. Alice receives a notification of this and renders this on
Alice's UI. Alice subsequently picks up the held call and has a
established session with Carol. Finally, Carol hangs up. Alice must
PUBLISH F32 to indicate that the INVITE F38 will be an attempt to
