RFC 7463
Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)
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<| | | | | |
|>F2 200 OK ----------------------------->| | | | | | | |<----- SUBSCRIBE F3<| | | | | | | |>F4 200 OK -------->| | | | | | | |>F5 NOTIFY -------->| | | | | | | |<-------- 200 OK F6<| | | | | | |<-------------------------------------------- REGISTER F7<| | | | | |>F8 200 OK ---------------------------------------------->| | | | | | |<---------------------- SUBSCRIBE F9<| | | | | | |>F10 200 OK ------------------------>| | | | | | |>F11 NOTIFY ------------------------>| | | | | | |<------------------------ 200 OK F12<| | | | | Figure 1. Registration and Subscription Example F1-F2: Alice registers AOR with contact: <sip:alice@ua1.example.com> F1 Alice ----> Registrar REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD To: <sip:HelpDesk@example.com> CSeq: 2 REGISTER Call-ID: d3281184-518783de-cc23d6bb Contact: <sip:alice@ua1.example.com> Max-Forwards: 70 Expires: 3600 Content-Length: 0 F2 Registrar ----> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 CSeq: 2 REGISTER Call-ID: d3281184-518783de-cc23d6bb
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD To: <sip:HelpDesk@example.com>;tag=1664573879820199 Contact: <sip:alice@ua1.example.com>;expires=3600 Content-Length: 0 F3 to F6: Alice also subscribes to the events associated with the Appearance AOR. Appearance Agent notifies Alice of the status. F3 Alice ----> Appearance Agent SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E To: <sip:HelpDesk@example.com> CSeq: 91 SUBSCRIBE Call-ID: ef4704d9-bb68aa0b-474c9d94 Contact: <sip:alice@ua1.example.com> Event: dialog;shared Accept: application/dialog-info+xml Max-Forwards: 70 Expires: 3700 Content-Length: 0 F4 Appearance Agent ----> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A CSeq: 91 SUBSCRIBE Call-ID: ef4704d9-bb68aa0b-474c9d94 From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E To: <sip:HelpDesk@example.com>;tag=1636248422222257 Allow-Events: dialog Expires: 3700 Contact: <sip:appearanceagent.example.com> Content-Length: 0 F5 Appearance Agent ----> Alice NOTIFY sip:alice@ua1.example.com SIP/2.0 From: <sip:HelpDesk@example.com>;tag=1636248422222257 To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E Call-ID: ef4704d9-bb68aa0b-474c9d94 CSeq: 232 NOTIFY Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active;expires=3000
Contact: <sip:appearanceagent.example.com>
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="40"
state="full"
entity="sip:HelpDesk@example.com">
</dialog-info>
F6 Alice ----> Appearance Agent
SIP/2.0 200 OK
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
CSeq: 232 NOTIFY
Call-ID: ef4704d9-bb68aa0b-474c9d94
Contact: <sip:alice@ua1.example.com>
Content-Length: 0
F7 Bob ----> Registrar
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
From: <sip:bob@example.com>;tag=34831131
To: <sip:HelpDesk@example.com>
CSeq: 72 REGISTER
Call-ID: 139490230230249348
Contact: <sip:bob@ua2.example.com>
Max-Forwards: 70
Expires: 3600
Content-Length: 0
F8 Registrar ----> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
From: <sip:bob@example.com>;tag=34831131
To: <sip:HelpDesk@example.com>;tag=fkwlwqi1
CSeq: 72 REGISTER
Call-ID: 139490230230249348
Contact: <sip:alice@ua1.example.com>;expires=3200 Contact: <sip:bob@ua2.example.com>;expires=3600 Content-Length: 011.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 -<| | | |
| |<--------- 180 Ringing F11<| | |< 180 F12 -<| | | | | | | | | | |<------------------------ 200 OK F13<| |< 200 F14 -<| | | | | | | | | | |>F15 CANCEL -------------->| | | | | | | | |<-------------- 200 OK F16<| | | | | | | | |<Request Cancelled 487 F17<| | | | | | | | |>F18 ACK ----------------->| | |>F19 ACK -->| | | | | |>F20 ACK --------------------------->| | | | | | |<=============Both way RTP established===========>| | | | | | | |< - - - - - >| | | | | | | | | | |>F21 NOTIFY >| | | | | | | | | |<- 200 F22 -<| | | | | | | | | |>F23 NOTIFY ---------->| | | | | | | | |<F24 200 OK ----------<| | | | | Figure 2. Appearance Selection for Incoming Call Example F4 Appearance Agent ----> Alice NOTIFY sip:alice@ua1.example.com SIP/2.0 From: <sip:HelpDesk@example.com>;tag=151702541050937 To: <sip:alice@example.com>;tag=18433323-C3D237CE Call-ID: 1e361d2f-a9f51109-bafe31d4 CSeq: 12 NOTIFY Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 Max-Forwards: 70 Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=2800 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="13"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345"
remote-tag="44BAD75D-E3128D42"
direction="recipient">
<sa:appearance>1</sa:appearance>
<state>trying</state>
<remote>
<identity>sip:carol@ua.example.com</identity>
</remote>
</dialog>
</dialog-info>
F7 Proxy ----> Bob
INVITE sip:bob@ua2.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
From: <sip:carol@example.com>;tag=44BAD75D-E3128D42
To: <sip:HelpDesk@example.com>
CSeq: 106 INVITE
Call-ID: 14-1541707345
Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69
Alert-Info: <urn:alert:service:normal>;appearance=1
Content-Type: application/sdp
Content-Length: ...
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F21 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=151702541050937
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 --------------------------------->|
|<-- INVITE F3<| | | | | |< - - - - - - - - - - - - - ->| | | | | | | | | |<-- NOTIFY F4<| | | | | | | | | |>F5 200 OK -->| | | | | |------- NOTIFY F6>| | | | | | | | | |<F7 200 OK ------<| |>F8 180 ---->| | | | | |>F9 180 Ringing -------------------------------->| | | | | | | |< - - - - - - - - - - - - - ->| | | | | | | | | |<- NOTIFY F10<| | | | | | | | | |>F11 200 OK ->| | | | | |------ NOTIFY F12>| | | | | | | | | |<F13 200 OK -----<| |>F14 200 OK ->| | | | | |>F15 200 OK ------------------------------------>| | | | | | | |<--------------------------------------- ACK F16<| |<---- ACK F17<| | | | | | | | | |<================= Both way RTP established ===================>| | | | | | | |< - - - - - - - - - - - - - ->| | | | | | | | | |<- NOTIFY F18<| | | | | | | | | |>F19 200 OK ->| | | | | |------ NOTIFY F20>| | | | | | | | | |<F21 200 OK -----<| | | | | | Figure 3. Outgoing Call without Appearance Seizure Example F1 Bob ----> Proxy INVITE sip:carol@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B To: <sip:carol@example.com> CSeq: 1 INVITE
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
Contact: <sip:bob@ua2.example.com>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua2.example.com
s=IP SIP UA
c=IN IP4 ua2.example.com
t=0 0
a=sendrecv
m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F4 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62
From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
Call-ID: ef4704d9-bb68aa0b-474c9d94
CSeq: 233 NOTIFY
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active;expires=2200
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" 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>
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
much of the dialog information from F7 as can be determined in
advance. In this case, the minimum of the Contact URI is included,
which allows the Appearance Agent to correlate the INVITE with the
PUBLISH.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| | |<-- NOTIFY F3<| |
| | | | |
| | |>F4 200 OK -->| |
| | | |------- NOTIFY F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F7<|
| | | | |
| |>F8 100 Trying --------------------------------->|
|<-- INVITE F9<| | | |
| | | |<---- PUBLISH F10<|
| | | | |
| | | |>F11 200 OK ----->|
| | | | |
|>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | |<F17 200 OK -----<|
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F20<|
|<---- ACK F21<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F22<| |
| | | | | | | |>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>
F2 Appearance Agent ----> Bob SIP/2.0 200 OK 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 SIP-Etag: 482943245 Allow-Events: dialog Expires: 60 Content-Length: 0 F7 Bob ---> Proxy INVITE sip:carol@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122 Max-Forwards: 70 From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B To: <sip:carol@example.com> Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 CSeq: 31 INVITE Contact: <sip:bob@ua2.example.com> Content-Type: application/sdp Content-Length: ... (SDP Not Shown) F10 Bob ----> Appearance Agent PUBLISH sip:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 From: <sip:bob@example.com>;tag=0CCf6-A7FdsB79D To: <sip:HelpDesk@example.com> CSeq: 437 PUBLISH Call-ID: fwF14d4-F1FFF2F2893K38424 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"
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<|
| | | | | | |>F8 100 Trying --------------------------------->| |<-- INVITE F9<| | | | | | | |<---- PUBLISH F10<| | | | | | | | | |>F11 200 OK ----->| | | | | | |>F12 180 --->| | | | | |>F13 180 Ringing ------------------------------->| | | | | | | |< - - - - - - - - - - - - - ->| | | | | | | | | |<- NOTIFY F14<| | | | | | | | | |>F15 200 OK ->| | | | | |------ NOTIFY F16>| | | | | | | | | |<F17 200 OK -----<| |>F18 200 OK ->| | | | | |>F19 200 OK ------------------------------------>| | | | | | | |<--------------------------------------- ACK F20<| |<---- ACK F21<| | | | | | | | | |<================= Both way RTP established ===================>| | | | | | | |< - - - - - - - - - - - - - ->| | | | | | | | | |<- NOTIFY F22<| | | | | | | | | |>F23 200 OK ->| | | | | |------ NOTIFY F24>| | | | | | | | | |<F25 200 OK -----<| | | | | | Figure 5. Outgoing Call without using an Appearance Number Example F1 Bob ----> Appearance Agent PUBLISH sip:appearanceagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 From: <sip:bob@example.com>;tag=4415df82k39sf 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: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
pickup the dialog between Carol and Bob and, hence, may use the same
appearance number. This example also shows Secure SIP (sips) being
used.
Carol Proxy Alice Appearance Agent Bob
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |<------------------------------(hold) INVITE F22<|
|<- INVITE F23<| | | |
| | | | |
|>F24 200 OK ->| | | |
| |>F25 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F26<|
|<---- ACK F27<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F28<| |
| | | | |
| | |>F29 200 OK ->| |
| | | |>F30 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F31<|
| | | | |
| | Alice decides to pick up the call |
| | | | |
| | |>F32 PUBLISH->| |
| | | | |
| | |<- 200 OK F33<| |
| | | | |
| | |<- NOTIFY F34<| |
| | | | |
| | |>F35 200 OK ->| |
| | | |>F36 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F37<|
| |<-- INVITE F38<| | |
|<- INVITE F39<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
|>F40 200 OK ->| | | |
| |>F41 200 OK -->| | |
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | | |>F42 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F43<|
| | |<- NOTIFY F44<| | | | | | | | | |>F45 200 OK ->| | | | | | | | |<----- ACK F46<| | | |<---- ACK F47<| | | | | | | | | |<= Both way RTP established =>| | | | | | | | |>F48 BYE ---->| | | | | |>F49 BYE --------------------------------------->| | | | | | | |<------------------------------------ OK 200 F50<| |<- 200 OK F51<| | | | | | | | | | |< - - - - - - - - - - - - - ->| | | | | | | | | |<- NOTIFY F52<| | | | | | | | | |>F53 200 OK ->| | | | | | | | | | |>F54 NOTIFY ----->| | | | | | | | | |<----- 200 OK F55<| Figure 7. Appearance Pickup Example F28 Appearance ----> Alice NOTIFY sips:alice@ua1.example.com SIP/2.0 From: <sips:HelpDesk@example.com>;tag=151702541050937 To: <sips:alice@example.com>;tag=18433323-C3D237CE Call-ID: 1e361d2f-a9f51109-bafe31d4 CSeq: 12 NOTIFY Via: SIP/2.0/TLS appearanceagent.example.com ;branch=z9hG4bK1403 Max-Forwards: 70 Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=1800 Contact: <sips: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="10"
state="partial"
entity="sips:HelpDesk@example.com">
<dialog id="id3d4f9c83"
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>active</state>
<local>
<target uri="sips:bob@ua2.example.com">
<param pname="+sip.rendering" pval="no"/>
</target>
</local>
<remote>
<identity>sips:carol@example.com</identity>
<target uri="sips:carol@ua3.example.com" />
</remote>
</dialog>
</dialog-info>
F32 Alice ----> Appearance Agent
PUBLISH sips:HelpDesk@example.com SIP/2.0
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sips:HelpDesk@example.com>;tag=44150CC6-A7B7919D
To: <sips:alice@example.com>;tag=428765950880801
CSeq: 11 PUBLISH
Call-ID: 87837Fkw87asfds
Contact: <sips:alice@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="10"
state="full"
entity="sips:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="3d57cd17-47deb849-dca8b6c6"
local-tag="8C4183CB-BCEAB710" >
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<sa:replaced-dialog
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
from-tag="15A3DE7C-9283203B"
to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" />
<state>trying</state>
<local>
<target uri="sips:alice@ua1.example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
<remote>
<target uri="sips:carol@ua3.example.com" />
</remote>
</dialog>
</dialog-info>
F38 Alice ----> Proxy
INVITE sips:carol@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
From: <sips:HelpDesk@example.com>;tag=8C4183CB-BCEAB710
To: <sips:carol@example.com:5075>
CSeq: 1 INVITE
Call-ID: 3d57cd17-47deb849-dca8b6c6
Contact: <sips:alice@ua1.example.com>
<all-one-line>
Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
</all-one-line>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980497 1102980497 IN IP4 ua1.example.com
s=IP SIP UA
c=IN IP4 ua1.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
(next page on part 4)
