RFC 7463
Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)
11.8. Call between UAs within the Group
In this scenario, Bob calls Alice who is also in the shared appearance group. Only one appearance number is used for this dialog. This example also shows the use of the 'exclusive' tag to indicate that other UAs in the group can not join or take this dialog. Carol Proxy Alice Appearance Agent Bob | | | | | | |<-------------------- INVITE (to Alice's UA) F1<| | | | | | | |< - - - - - - - - - - - - - ->| | | | | | | | | | | | | | |<-- NOTIFY F2<| | | | | | | | | |>F3 200 OK -->| | | | | |>F4 NOTIFY ------>| | | | | | | | | |<------ 200 OK F5<| | |>F6 INVITE --->| | | | | (appearance=1)| | | | | | | | | |<------ 180 F7<| | | | | | | | | |>F8 180 --------------------------------------->| | | | | | | |< - - - - - - - - - - - - - ->| | | | | | | | | |<-- NOTIFY F9<| | | | | | | | | |>F10 200 OK ->| | | | | |>F11 NOTIFY ----->| | | | | | | | | |<----- 200 OK F12<| | |<-- 200 OK F13<| | | | | | | | | |>F14 200 OK ------------------------------------>| | | | | | | |<--------------------------------------- ACK F15<| | | | | | | |>F16 ACK ----->| | | | | | | | | | |<======= RTP established =======>| | | | | | | |< - - - - - - - - - - - - - ->| | | | | | |
| | |<- NOTIFY F17<| | | | | | | | | |>F18 200 OK ->| | | | | |>F19 NOTIFY ----->| | | | | | | | | |<----- 200 OK F24<| | | | | | Figure 8. Call between UAs within the Group Example F19 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=1500 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="10" state="partial" entity="sip:HelpDesk@example.com"> <dialog id="3xdsd4f9c83" call-id="b3cbd0-ad2c5775e-5df9f8d5" local-tag="34322kdfr234f" remote-tag="3153DE7C-928203B" direction="initiator"> <sa:exclusive>true</sa:exclusive> <sa:appearance>1</sa:appearance> <state>confirmed</state> <local> <target uri="sip:bob@ua2.example.com"> </target> </local> <remote> <identity>sip:HelpDesk@example.com</identity> <target uri="sip:alice@ua1.example.com" />
</remote>
</dialog>
<dialog id="4839589"
call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="3153DE7C-928203B"
remote-tag="34322kdfr234f"
direction="responder">
<sa:exclusive>true</sa:exclusive>
<sa:appearance>1</sa:appearance>
<state>confirmed</state>
<local>
<target uri="sip:alice@ua1.example.com" />
</local>
<remote>
<identity>sip:HelpDesk@example.com</identity>
<target uri="sip:bob@ua2.example.com" />
</remote>
</dialog>
</dialog-info>
11.9. Consultation Hold with Appearances
In this scenario, Bob has a call with Carol. Bob makes a
consultation call to Alice by putting Carol on hold and calling
Alice. Bob's UA chooses not to have an appearance number for the
call to Alice since it is treating it as part of the call to Carol.
He indicates this in the PUBLISH F32, which contains the 'shared'
Event header field parameter but no <appearance> element. The
PUBLISH is sent before the INVITE to Alice to ensure no appearance
number is assigned by the Appearance Agent. Finally, Bob hangs up
with Alice and resumes the call with Carol. Dialog notifications of
the consultation call are not shown, as they are not used.
Note that if Carol hangs up while Bob is consulting with Alice, Bob
can decide if he wants to reuse the appearance number used with Carol
for the call with Alice. If not, Bob publishes the termination of
the dialog with Carol and the Appearance Agent will re-allocate the
appearance. If he wants to keep the appearance, Bob will publish the
termination of the dialog with Carol and also publish the appearance
with the dialog with Alice. This will result in Bob keeping the
appearance number until he reports the dialog with Alice terminated.
Note that the call flow would be similar if Bob called a music on
hold server instead of Alice to implement a music on hold service as
described in [RFC7088].
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<|
| | | | |
| | Bob makes a consultation call to Alice |
| | | | |
| | | |<---- PUBLISH F32<|
| | | | |
| | | |>F33 200 OK ----->|
| | | | |
| |<------------------------------------ INVITE F34<|
| | | | |
| |>F35 INVITE -->| | |
| | | | |
| |<-- 200 OK F36<| | |
| | | | |
| |>F37 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F38<|
| | | | |
| |>F39 ACK ----->| | |
| | | | |
| | |<======= RTP established =======>|
| | | | |
| | Bob hangs up with Alice |
| | | | |
| |<--------------------------------------- BYE F40<|
| | | | |
| |>F41 BYE ----->| | |
| | | | |
| |<-- 200 OK F42<| | |
| | | | | | |>F43 200 OK ------------------------------------>| | | | | | | |<----------------------------(unhold) INVITE F44<| |<- INVITE F45<| | | | | | | | | |>F46 200 OK ->| | | | | |>F47 200 OK ------------------------------------>| | | | | | | |<--------------------------------------- ACK F48<| |<---- ACK F49<| | | | | |< - - - - - - - - - - - - - ->| | | | | | | | | |<- NOTIFY F50<| | | | | | | | | |>F51 200 OK ->| | | | | |>F52 NOTIFY ----->| | | | | | | | | |<----- 200 OK F53<| | | | | | |<================= Both way RTP established ===================>| | | | | | Figure 9. Consultation Hold with Appearances Example F32 Bob ----> Appearance Agent PUBLISH sip:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A From: <sip:bob@example.com>;tag=44150CC6-A7B7919D To: <sip:HelpDesk@example.com>;tag=428765950880801 CSeq: 11 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="10" state="full" entity="sip:HelpDesk@example.com"> <dialog id="id3d4f9c83" call-id="b3cbd0-ad2c5775e-5df9f8d5" local-tag="3153DE7C-928203B"
direction="initiator">
<sa:exclusive>true</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
<remote>
<identity>sip:HelpDesk@example.com</identity>
<target uri="sip:alice@ua1.example.com" />
</remote>
</dialog>
</dialog-info>
11.10. Joining or Bridging an Appearance
In this call flow, a call answered by Bob is joined by Alice or
"bridged". The Join header field is used by Alice to request this
bridging. If Bob did not support media mixing, Bob could obtain
conferencing resources as described in [RFC4579].
Carol Forking Proxy Appearance Agent Alice Bob
| | | | |
|<=============Both way RTP established===========>|
| | | | |
| | |< PUBLISH F22| |
| | | | |
| | |>F23 200 OK >| |
| | | | |
| |<---- INVITE (w/ Join) F24<| |
| | | | |
| |>F25 INVITE (w/Join)---------------->|
| | | | |
| |<---- OK 200 Contact:Bob;isfocus F26<|
| | | | |
| |< - - - - - >| | |
| | | | |
| | |>F27 NOTIFY >| |
| | | | |
| | |< 200 OK F28<| |
| | | | |
| | |>F29 NOTIFY ---------->|
| | | | |
| | |<F30 200 OK ----------<|
| | | | |
| |>F31 200 OK Contact:B----->| |
| | | | |
| |<----------------- ACK F32<| |
| | | | | | |>ACK F33---------------------------->| | | | | | | |<-----INVITE Contact:Bob;isfocus F34<| |<-INVITE F35| | | | | | | | | |>F26 200 -->| | | | | |>F37 200 OK ------------------------>| | | | | | | |<--------------------------- ACK F38<| |<--- ACK F39| | | | | | | |<==RTP==>| |<=============Both way RTP established===========>| | | | | | | |< - - - - - >| | | | | | | | | | |>F40 NOTIFY >| | | | | | | | | |< 200 OK F41<| | | | | | | | | |>F42 NOTIFY ---------->| | | | | | | | |<F43 200 OK ----------<| | | | | | Figure 10. Joining or Bridging an Appearance Example F22 Alice ----> Appearance Agent PUBLISH sip:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A From: <sip:alice@example.com>;tag=44150CC6-A7B7919D To: <sip:HelpDesk@example.com>;tag=428765950880801 CSeq: 11 PUBLISH Call-ID: 87837Fkw87asfds Contact: <sip: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="sip:HelpDesk@example.com:5060"> <dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" >
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<sa:joined-dialog
call-id="14-1541707345"
from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<state>trying</state>
<local>
<target uri="sip:alice@ua1.example.com">
</target>
</local>
<remote>
<target uri="sip:bob@example.com" />
</remote>
</dialog>
</dialog-info>
F24 Alice ----> Proxy
INVITE sip:bob@ua.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31
From: <sip:HelpDesk@example.com>;tag=605AD957-1F6305C2
To: <sip:bob@ua.example.com>
CSeq: 2 INVITE
Call-ID: dc95da63-60db1abd-d5a74b48
Contact: <sip:alice@ua1.example.com>
<all-one-line>
Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5
-b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42
</all-one-line>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1103061265 1103061265 IN IP4 ua1.example.com
s=IP SIP UA
c=IN IP4 ua1.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
11.11. Loss of Appearance during Allocation
Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, then becomes unreachable. When he fails to refresh his publication to the appearance agent, the Appearance Agent declares the dialog terminated and frees up the appearance using NOTIFYs F14 and F16. After retransmitting the NOTIFY to Bob (in not shown messages F17, F18, etc.), the subscription is terminated. 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 ------------------------------->| | | | | | | | | | Bob goes offline | | | | | | | | | Appearance selection times out | | | | | | | | |<- NOTIFY F14<| | | | | | | | | |>F15 200 OK ->| | | | | |------ NOTIFY F16>| | | | | | | | | NOTIFY is retransmitted | Figure 11. Loss of Appearance during Allocation Example
11.12. Appearance Seizure Contention Race Condition
Bob and Alice both try to reserve appearance 2 by publishing at the same time. The Appearance Agent allocates the appearance to Bob by sending a 200 OK and denies it to Alice by sending a 400 (Bad Request) response. After the NOTIFY F5, Alice learns that Bob is using appearance 2. Alice then attempts to reserve appearance 3 by publishing, which is then accepted.
Carol Proxy Alice Appearance Agent Bob | | | | | | | | |<----- PUBLISH F1<| | | | | (appearance=2) | | |>F2 PUBLISH ->| | | | | (appearance=2) | | | | | | | | | |>F3 200 OK ------>| | | |<---- F4 400 <| | | | | | | | | |<-- NOTIFY F5<| | | | | | | | | |>F6 200 OK -->| | | | | |------- NOTIFY F7>| | | | | | | | | |<F8 200 OK ------<| | | | | | | |<------------------------------------- INVITE F9<| | | | | | | |>F10 100 Trying -------------------------------->| |<- INVITE F11<| | | | | | | |<---- PUBLISH F12<| | | | | (appearance=2) | | | |>F13 200 OK ----->| | | |>F14 PUBLISH->| | | | | (appearance=3) | | | | | | | | |<--- F15 200 <| | | | | | | | | |<- NOTIFY F16<| | | | | | | | | |>F17 200 OK ->| | Dave | | |------ NOTIFY F18>| | | | | | | | | |<F19 200 OK -----<| | |<-- INVITE F20<| | | | | | | | | |>F21 100 ----->| | | |<- INVITE F22<| | | | Figure 12. Appearance Seizure Contention Race Condition Example11.13. Appearance Agent Subscription to UAs
In this scenario, the Appearance Agent does not have any way of knowing Bob's dialog state information, except through Bob. This could be because the Appearance Agent is not part of a B2BUA, or
perhaps Bob is remotely registering. When Bob registers, the
Appearance Agent receives a registration event package notification
from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's
dialog event state using Event:dialog in the SUBSCRIBE. Whenever
Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance
Agent which then notifies the other UAs in the group.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| |<----------------------------------- REGISTER F1<|
| | | | |
| |>F2 200 OK ------------------------------------->|
| | | | |
| |>F3 NOTIFY ------------------>| |
| | | | |
| |<------------------ 200 OK F4<| |
| | | |---- SUBSCRIBE F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| | | |<------ NOTIFY F7<|
| | | | |
| | | |>F8 200 OK ------>|
| | | | |
| | | |<--- SUBSCRIBE F9<|
| | | | |
| | | |>F10 200 OK ----->|
| | | | |
| | | |------ NOTIFY F11>|
| | | | |
| | | |<F12 200 OK -----<|
| | | | |
| |<------------------------------------ INVITE F13<|
| | | | |
| |>F14 100 Trying -------------------------------->|
|<- INVITE F15<| | | |
| | | |<----- NOTIFY F16<|
| | | | |
| | | |>F17 200 OK ----->|
| | |<- NOTIFY F18<| |
| | | | |
| | |>F19 200 OK ->| |
| | | |------ NOTIFY F20>|
| | | | |
| | | |<F21 200 OK -----<|
|>F22 180 --->| | | |
| |>F23 180 Ringing ------------------------------->|
| | | | |
| | | |<----- NOTIFY F24<| | | | | | | | | |>F25 200 OK ----->| | | |<- NOTIFY F26<| | | | | | | | | |>F27 200 OK ->| | | | | |------ NOTIFY F28>| | | | | | | | | |<F29 200 OK -----<| |>F30 200 OK ->| | | | | |>F31 200 OK ------------------------------------>| | | | | | | | | |<----- NOTIFY F32<| | | | | | | | | |>F33 200 OK ----->| | | | | | | |<--------------------------------------- ACK F34<| |<---- ACK F35<| | | | | | | | | |<================= Both way RTP established ===================>| | | | | | | | |<- NOTIFY F36<| | | | | | | | | |>F37 200 OK ->| | | | | |------ NOTIFY F38>| | | | | | | | | |<F39 200 OK -----<| | | | | | Figure 13. Appearance Agent Subscription to UAs Example11.14. Appearance Pickup Race Condition Failure
In this scenario, Bob has an established dialog with Carol created using the call flows of Figure 1 or Figure 2. Bob then places Carol on hold. Alice receives a notification of this and renders this on Alice's UI. Alice attempts to pick up the call but Carol hangs up before the pickup can complete. Alice cancels the pickup attempt with the PUBLISH F48. Note that the call flow for a failed Join would be almost identical. 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<|
|>F38 BYE ---->| | | |
| |>F39 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ OK 200 F40<|
|<- 200 OK F41<| | | |
| |<-- INVITE F42<| | |
|<- INVITE F43<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
| | | | |
|>F44 481 ---->| | | |
| |>F45 481 ----->| | |
|<---- ACK F46<| | | |
| |<----- ACK F47<| | |
| | |>F48 PUBLISH->| |
| | | | |
| | |<- 200 OK F49<| |
| | | | |
| | |<- NOTIFY F50<| |
| | | | |
| | |>F51 200 OK ->| |
| | | |>F52 NOTIFY ----->| | | | | | | | | |<----- 200 OK F53<| Figure 14. Appearance Pickup Race Condition Failure Example F48 Alice ----> Appearance Agent PUBLISH sip:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A From: <sip:alice@example.com>;tag=44150CC6-A7B7919D To: <sip:HelpDesk@example.com>;tag=428765950880801 CSeq: 11 PUBLISH Call-ID: 87837Fkw87asfds Contact: <sip: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="sip:HelpDesk@example.com"> <dialog id="id3d4f9c83" call-id="dc95da63-60db1abd-d5a74b48" local-tag="605AD957-1F6305C2" > <sa:appearance>1</sa:appearance> <sa:exclusive>false</sa:exclusive> <sa:replaced-dialog call-id="14-1541707345" from-tag="44BAD75D-E3128D42" to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> <state>terminated</state> <local> <target uri="sip:alice@ua1.example.com"> </target> </local> <remote> <target uri="sip:carol@ua3.example.com" /> </remote> </dialog> </dialog-info>
11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition
Alice tries to seize appearance 2 at the same time appearance 2 is allocated to an incoming call. The Appearance Agent resolves the conflict by sending a 400 (Bad Request) to Alice. After the NOTIFY F6, Alice learns that the incoming call is using appearance 2. Alice republishes for appearance 3, which is accepted. Note that this example shows the INVITE being received before the NOTIFY from the Appearance Agent.
Carol Proxy Alice Appearance Agent Bob | | | | | |>-- INVITE F1>| | | | | |< - - - - - - - - - - - - - ->| | | | | | | | | |>F2 PUBLISH ->| | | | | (appearance=2) | | | | | | | |>F3 INVITE (appearance=2) ---------------------->| | | | | | | |>F4 INVITE | | | | |(appearance=2)>| | | | | |<---- F5 400 <| | | | | | | | | |<-- NOTIFY F6<| | | | | | | | | |>F7 200 OK -->| | | | | |------- NOTIFY F8>| | | | | | | | | |<F9 200 OK ------<| | | | | | | | |>F10 PUBLISH->| | | | | (appearance=3) | | | | | | | | |< F11 200 OK <| | | | | | | | | |<- NOTIFY F12<| | | | | | | | |>F13 200 OK ->| | Dave | | |------ NOTIFY F14>| | | | | | | | | |<F15 200 OK -----<| | |<-- INVITE F16<| | | | | | | | | |>F17 100 ----->| | | |<- INVITE F18<| | | | Figure 15. Appearance Seizure Incoming/Outgoing Contention Race Condition Example12. Security Considerations
Since multiple line appearance features are implemented using semantics provided by SIP [RFC3261], the SIP Event Package for Dialog State [RFC4235], and the SIP Event Framework [RFC6665] and [RFC3903], security considerations in these documents apply to this document as well.
To provide confidentiality, NOTIFY or PUBLISH message bodies that provide the dialog state information and the dialog identifiers MAY be encrypted end-to-end using the standard mechanisms such as S/MIME described in [RFC3261]. Alternatively, sending the NOTIFY and PUBLISH requests over TLS also provides confidentiality, although on a hop-by-hop basis. All SUBSCRIBEs and PUBLISHes between the UAs and the Appearance Agent MUST be authenticated. Without proper authentication and confidentiality, a third party could learn information about dialogs associated with a AOR and could try to use this information to hijack or manipulate those dialogs using SIP call control primitives. This feature relies on standard SIP call control primitives such as Replaces and Join. Proper access controls on their use MUST be used so that only members of the shared appearance group can use these mechanisms. All INVITEs with Replaces or Join header fields MUST only be accepted if the peer requesting dialog replacement or joining has been properly authenticated using a standard SIP mechanism (such as Digest or S/MIME), and authorized to request a replacement. Otherwise, a third party could disrupt or hijack existing dialogs in the shared appearance group. For an emergency call, a UA MUST NOT wait for a confirmed seizure of an appearance before sending an INVITE. Waiting for confirmation could inadvertently delay or block the emergency call, which by its nature needs to be placed as expeditiously as possible. Instead, a emergency call MUST proceed regardless of the status of the PUBLISH transaction.13. IANA Considerations
This section registers the SIP Event header field parameter 'shared', the SIP Alert-Info header field parameter 'appearance', and the XML namespace extensions to the SIP Dialog Package.13.1. SIP Event Header Field Parameter: shared
This document defines the 'shared' header field parameter in the Event header field in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968]. Predefined Header Field Parameter Name Values Reference ---------------------------- ------------------ ---------- --------- Event shared No RFC 7463
13.2. SIP Alert-Info Header Field Parameter: appearance
This document defines the 'appearance' parameter in the Alert-Info header in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968]. Predefined Header Field Parameter Name Values Reference ---------------------- --------------- --------- --------- Alert-Info appearance No RFC 746313.3. URN Sub-Namespace Registration: sa-dialog-info
This section registers a new XML namespace per the procedures in [RFC3688]. URI: urn:ietf:params:xml:ns:sa-dialog-info. Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, Alan Johnston <alan.b.johnston@gmail.com> XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Shared Appearance Dialog Information Namespace</title> </head> <body> <h1>Namespace for Shared Appearance Dialog Information</h1> <h2>urn:ietf:params:xml:ns:sa-dialog-info</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc7463.txt"> RFC 7463</a>.</p> </body> </html> END13.4. XML Schema Registration
This section registers an XML schema per the procedures in [RFC3688].
URI: urn:ietf:params:xml:schesa:sa-dialog-info.
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan.b.johnston@gmail.com>
The XML for this schema can be found in Section 6.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003,
<http://www.rfc-editor.org/info/rfc3515>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September
2004, <http://www.rfc-editor.org/info/rfc3891>.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004,
<http://www.rfc-editor.org/info/rfc3903>.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004,
<http://www.rfc-editor.org/info/rfc3911>.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004, <http://www.rfc-editor.org/info/rfc3968>. [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005, <http://www.rfc-editor.org/info/rfc4235>. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012, <http://www.rfc-editor.org/info/rfc6665>. [RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and P. Kyzivat, "URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)", RFC 7462, March 2015, <http://www.rfc-editor.org/info/rfc7462>.14.2. Informative References
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004, <http://www.rfc-editor.org/info/rfc3680>. [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006, <http://www.rfc-editor.org/info/rfc4579>. [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008, <http://www.rfc-editor.org/info/rfc5359>. [RFC7088] Worley, D., "Session Initiation Protocol Service Example -- Music on Hold", RFC 7088, February 2014, <http://www.rfc-editor.org/info/rfc7088>.
Acknowledgements
The following individuals were part of the shared appearance design team and have provided input and text to the document (in alphabetical order): Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek MacDonald, Bill Mitchell, Michael Procter, and Theo Zourzouvillys. Thanks to Chris Boulton for helping with the XML schema. Much of the material has been drawn from previous work by Mohsen Soroushnejad, Venkatesh Venkataramanan, Paul Pepper, and Anil Kumar, who in turn received assistance from: Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems; Steve Towlson and Michael Procter of Citel Technologies; Rob Harder and Hong Chen of Polycom, Inc.; John Elwell and JD Smith of Siemens Communications; Dale R. Worley of Pingtel; and Graeme Dollar of Yahoo, Inc. Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their comments. Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji Chinnappa, and Harsh Mendiratta for their detailed review of the document.Authors' Addresses
Alan Johnston (editor) Avaya St. Louis, MO United States EMail: alan.b.johnston@gmail.com Mohsen Soroushnejad (editor) Sylantro Systems Corp. EMail: msoroush@gmail.com
Venkatesh Venkataramanan Sylantro Systems Corp. EMail: vvenkatar@gmail.com