Broadsoft BroadWork SIP

BROADWORKS SIP ACCESS SIDE EXTENSIONS INTERFACE SPECIFICATIONS RELEASE 13.0 Versio Version n1

BroadWorks® Guide

Copyright Notice Copyright © 2005 BroadSoft, Inc. All rights rights reserv reserved. ed. Any technic technical al documen documentat tation ion that that is is made made availabl available e by by Broa BroadSo dSoft, ft, Inc. Inc. is is prop proprie rietar tary y and and confidential and is considered the copyrighted work of BroadSoft, Inc. This publication is for distribution under BroadSoft non-disclosure agreement only. No part of this publication may be duplicated without the express written permission of BroadSoft, Inc. 220 Perry Parkway, Gaithersburg, MD 20877. BroadSoft reserves the right to make changes without prior notice.

Trademarks BroadSoft® and BroadWorks® are registered trademarks of BroadSoft, Inc. Microsoft, MSN, Windows, and the Windows logo are registered trademarks of Microsoft Corporation. Other product names mentioned in this manual may be trademarks trademarks or registered trademarks of their respective companies and are hereby acknowledged. This document is printed in the United States of America.

BROADWORKS SIP ACCESS SIDE EXTENSIONS INTERFACE SPECIFICATIONS ©

2005 BROADSOFT INC. PROPRIETARY AND CONFIDENTIAL; DO NOT DUPLICATE, OR DISTRIBUTE.

05-BD5031-00 PAGE 2 OF 39

Table of Contents 1

Intr oduc od ucti tion on ............. ................... ............ ............ ............. ............. ............ ............ ............ ............ ............. ............. ............ ............ ............ ............. .........6 ..6

2

Info-Param Inf o-Parameter eter Ext Extens ensio ions ns to “ Call-Info Call-In fo”” ............ ................... ............. ............ ............ ............ ............. ............. .........7 ...7 2.1

Overview ............................. ............................................ ............................. ............................. ............................. ............................ ................... ..... 7

2.2 Appeara Appearance nce-in -index, dex, Appeara Appearance nce-st -state ate,, and and Appeara Appearance nce-UR -URII ...... ......... ...... ...... ...... ...... ..... 7 2.2.1

In INVITE requests ............................. ........................................... ............................. ............................. ...................... ........ 8

2.2.2

In responses................... responses................................. ............................ ............................. ............................. ............................. ............... 9

2.2.3

In SUBSCRIBE requests................................ requests............................................... .............................. ...................... ....... 11

2.3

3

4

Call-Info “Answer-After” Info-parameter .............................. ............................................ ......................... ...........11 11 2.3.1

Overview ............................. ............................................ .............................. ............................. ............................. ..................... ...... 11

2.3.2

Example Message Flow ............................ ........................................... .............................. ........................... ............12 12

Call-Info Call-In fo Event Package......... Pack age............... ............. ............. ............ ............ ............ ............. ............. ............ ............ ............. ............. ........14 ..14 3.1

Overview .............................. ............................................. ............................. ............................. .............................. .............................. ...............14 14

3.2

Example Message Flow.............. Flow ............................. .............................. .............................. ............................. ..................... ....... 14 3.2.1

Shared Call Appearance Client Subscription..................................... Subscription.....................................14 14

3.2.2

Outgoing Call ............................. ............................................ .............................. ............................. ............................ ..............16 16

3.3

Event Package Name .............................. ............................................. ............................. ............................. ........................ ......... 21

3.4

Event Package Parameters ............................ .......................................... ............................. .............................. ................. .. 22

3.5

SUBSCRIBE Bodies Bodie s ............................. ............................................ .............................. .............................. .......................... ...........22 22

3.6

Subscription Duration ............................ ........................................... .............................. .............................. .......................... ...........22 22

3.7

NOTIFY Bodies.................................. Bodies................................................. ............................. ............................. .............................. ................. 22

3.8

Subscriber Generation of SUBSCRIBE Requests .............................. ...................................... ........22 22

3.9

Notifier Processing of SUBSCRIBE Requests....................................... Requests............................................. ...... 22

3.10

Notifier Generation of NOTIFY Requests ............................ ........................................... ....................... ........22 22

3.11

Subscriber Processing of NOTIFY Requests.................................... Requests............................................. ......... 23

3.12

Handling of Forked Requests............................... Requests.............................................. ............................. ........................ .......... 23

3.13

Rate of Notifications............... Notifications ............................. ............................. .............................. .............................. .......................... ...........23 23

Line-Seize Li ne-Seize Event Packag e ............ .................. ............. ............. ............ ............ ............. ............. ............ ............ ............ ............. ........24 .24 4.1

Overview .............................. ............................................. ............................. ............................. .............................. .............................. ...............24 24

4.2

Example Message Flows Fl ows............... ............................. ............................. .............................. .............................. ................... .... 25

4.3

Event Package Name .............................. ............................................. ............................. ............................. ........................ ......... 26

4.4


4.5


4.6


4.7


4.8


4.9


4.10


4.11


4.12




05-BD5031-00 PAGE 3 OF 39

4.13 5

6

7


Remot e Contr Con trol ol Talk Event Package Pack age ............ ................... ............. ............ ............ ............. ............. ............ ............ ........29 ..29 5.1

Overview .............................. ............................................. ............................. ............................. .............................. .............................. ...............29 29

5.2

Example Message Flow.............. Flow ............................. .............................. .............................. ............................. ..................... ....... 29

5.3

Event Package Names............................. Names........................................... ............................. .............................. ........................ ......... 31

5.4


5.5


5.6


5.7


5.8


5.9


5.10


5.11


5.12


5.13


Remot e Cont rol ro l Hol d Event Ev ent Packag e ............ ................... ............. ............ ............ ............. ............. ............ ............ .......34 .34 6.1

Overview .............................. ............................................. ............................. ............................. .............................. .............................. ...............34 34

6.2

Example Message Flow.............. Flow ............................. .............................. .............................. ............................. ..................... ....... 34

6.3

Event Package Names............................. Names........................................... ............................. .............................. ........................ ......... 36

6.4


6.5


6.6


6.7


6.8


6.9


6.10


6.11


6.12


6.13


Ind ex ...................................................................................................................... 38



05-BD5031-00 PAGE 4 OF 39

Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5

Message Flow as a Result Result of Click-To-Dial Operation................................... Operation................................................. ........................... ............. 12 Call Flow as a Result of Endpoint A-1 Originating a Call to B using A’s Shared Line............. Line ............. 16 Call Flow as a Result of a User at A-1 Taking the Shared Line Off Hook................ Hook ............................... ................. 25 Click-To-Answer Call Flow ............................. ............................................ .............................. .............................. ............................. ............................. .................. ... 29 Click-To-Hold Call Flow........................... Flo w.......................................... .............................. .............................. ............................. ............................. ......................... .......... 35



05-BD5031-00 PAGE 5 OF 39

1

Introduction This document describes extensions to the Session Initiation Protocol (SIP) that can be used to enable traditional voice applications, including but not limited to: key system emulation, executive-admin station emulation, push to talk, click to dial, and other remote control CTI applications. These extensions are typically employed between a line side “application server” and an end-user agent, agent, such as an IP phone or soft client. Application servers employing these extensions can provide a tightly integrated end-user experience and a rich service offering without being tightly coupled to the access device. Note that these extensions compliment existing standards and draft extensions aimed at integrating end-user access equipment with operator-hosted service platforms. These extensions have been adopted and implemented by many equipment vendors in the industry, including IP PBX vendors, IP phone vendors, access gateway vendors, and application server vendors.



05-BD5031-00 PAGE 6 OF 39

2

2.1

Info-Para Info-Parameter meter Extensions Extensions to “ Call-I Call-Info” nfo”

Overview In many traditional voice applications, it is important for the endpoint and the service delivery platform to maintain consistent “presentation” information. By this we mean, the the relative order of call appearances on a line and the current state of the call appearances. This enables call control clients, attendant consoles, and other applications to maintain a synchronized view of call appearance information, so that end users can move from one endpoint or one interface to another, without being confused. The Call-Info header is specified in RFC 3261. It is used to provide additional information about the calling or called party, depending on whether it is found in a request or a response. Here we use this header to send “presentation” information information about the call appearances associated with a given address of record (that is, a line). An excerpt from the augmented BNF in RFC 3261 follows for the Call-Info header: Cal l - I nf o = " Cal l - I nf o" HCOLON i nf o *( COMMA i nf o) i nf o = LAQUOT absol absol ut eUR eURI RAQUOT *( SEM SEMI i nf o- par par am) i nf o- par am = ( "pu "pur pose" se" EQUAL ( "i con con" / "i nf o" / "car "car d" / t oken ken) ) / gener i c- par am

This shows that the Call-Info header allows for comma delimited information elements. Each element must have an absolute URI – and each element can optionally have an arbitrary number of information parameters.

2.2

App earance-ind ex, App earance-state, and App earance-URI For this extension, the absolute URI should be a simple hostname SIP URI with no user portion. The host name should be set to the provisioned proxy server or in this case, the Applicat Application ion Server Server.. Three Three new generic generic parame parameter ters s are are defined defined for indicat indicating ing call information element parameters: “appea “appearr anceance- i ndex” ndex” EQ EQUAL ( ( 1*DI GI T) / STA STAR ) ) “ap “appear ancece- st at e” EQUAL ( “i dl e” / “sei “sei zed zed” / “pr “pr ogr essi ng” / “al “al er t i ng” / “acti “acti ve” / “he “hel d” / “he “hel d- pri vat e” ) “app “appear ear anceance- ur i ” EQUAL quot quot eded- st r i ng

For usability reasons, it is important to preserve the relative order of these call appearance across endpoints. The appearance-index parameter is used to qualify the call information elements, by identifying a relative index of the call appearance on the line. So if the appearance-index is 1, it indicates the first appearance on the line. If the appearanceindex is 2, it indicates the second appearance on the line, and so on, up to the maximum number of appearances allowed on the line. NOTE:

An appearance appearance-index of “*” is a shorthand form, indicating that the the information element is applicable to the rest of the call appearances on the line.

The appearance-state is used to further qualify the call appearance with an actual visual state that can be used to light a lamp, or display an LED or bitmap on an LCD display. The defined states are:



05-BD5031-00 PAGE 7 OF 39

State

Description

Idle

This appearance on the line is available for use.

Seized

This appearance has been seized by one of the endpoints in the SCA group.

Progressing

This appearance on the line is currently making an outgoing call.

Alerting

This appearance is receiving receiving an incoming call. call.

Active

This appearance is actively actively involved in a call.

Held

This appearance has a call in the held state.

Held-private

This appearance has a call in the held state and only the endpoint which held the call, may retrieve it.

The appearance-URI is used to further qualify the call appearance with the remote call party identification, which devices can use to augment the display, if they support this capability on the device. The value of the appearance-URI parameter is a SIP quotedstring that contains a SIP name-addr (that is, the the contents are “name-addr”). Since the name-addr is within a quoted-string, it is escaped according to the SIP escaping rules. The appearance-URI parameter is not included when the call appearance’s state is idle or seized, since there is no call involved with the call appearance in these states. 2.2.1

In INVITE INVITE requ ests A UAC UAC may include include a Call-Info header when sending an INVITE request. If it does, it must contain at most one call appearance information element. It may contain other information elements for different purposes, but only one call appearance information element should be present. The call appearance information element must contain exactly one appearance-index parameter with a numeric value. The numeric value indicates the call appearance index where the call is being presented. So, for example, assume a phone has one line with four separate call appearances, and the user interface on the phone allows the end user to arbitrarily select any one of the call appearances when originating a call. If the user chose the the third call appearance, then the INVITE might look something like the following: I NVI TE si p: 5551 555121 212@ 2@ broad br oadw wor ks. net net … Fr om: … To: To: … Cal l - I nf o: ; app appear ear anceance- i ndex= ex=3 …

Effectively the phone is saying: “The user has selected the third call appearance of line 5551000 to call 5551212”. Note that the Call-Info header is not required to be present in a Re-INVITE, but if present, the Re-INVITE must use the same appearance-index (that is, a Re-INVITE is not allowed to change the appearance-index being used). When BroadWorks is acting as the UAC, the device must honor the appearance-index included in an INVITE. In a race condition where the device initiates a line-seize for an appearance-index at the same time as BroadWorks sends an INVITE to the device for the same appearance-index, the device should allow the INVITE for the incoming call to proceed. A failure response to the line-seize SUBSCRIBE will be received by the device shortly afterwards.



05-BD5031-00 PAGE 8 OF 39

When the device is acting as the UAC and includes the appearance-index in an INVITE, BroadWorks may choose to override the appearance-index in the response, as described in Section 2.2.2 2.2.2.. An endpoint designates a call as privately privately held, by sending a re-INVITE with hold SDP including a call-info header with an appearance-state of held-private. BroadWorks, upon receipt of the re-INVITE for hold, inspects the call-info header and updates the state for the the call appearance to held-private. All shared call appearances with subscriptions to the call-info package i n the group are updated via NOTIFYs with the held-private call appearance state. Following is an example of the re-INVITE with hold SDP, which is privately held:

I NVI TE si p: 5551 555121 212@ 2@br oadw oadwor ks. net net … Fr om: … To: … Cal l - I nf o: ; appear ancece- st at e=hel d- pr i vat vat e … Following is the resulting NOTIFYs sent to the shared call appearances in the group:

NOTI FY si p: cont cont act @end endpoi nt … Fr om: … To: … Cal l - I nf o: ; appearance arance-i ndex= ex=1; app appear ear anceancest at e=hel d- pr i vat vat e; app appear ear anceancei ndex= ex=*; app appear ear anceancest at e=i dl e

When an endpoint in the sha red call appearance group attempts to retrieve a privately held call appearance which it did not put on hold, BroadWorks rejects the reINVITE retrieval attempt with a 403 Forbidden. BroadSoft recommends that devices use the same lamp state for held-private calls that they use for active calls. The recommended active lamp state for all of the other other endpoints which are not actively involved in the the call is a solid red indicator. However, the held-private state is propagated to all of the endpoints in the shared call appearance group, such that an endpoint may choose a different visual indication for privately held calls. 2.2.2 2.2.2

In respo nses Similarly, a UAS may include a Call-Info header when responding to an INVITE request. Call-Info headers with call appearance information elements may appear in any provisional or final response. They follow similar rules for Call-Infos sent in INVITE requests by UACs. So in the above example, assume the endpoint that receives the call for the address of record [email protected] [email protected] allows allows up to to six call appearances. At the time that this INVITE arrives at the endpoint, assume there are three calls present on the first three call appearances. So the phone chooses the next available call appearance (4) and sends back a provisional response: SI P/ 2. 0 18 180 Ri Ri ngi ng … Fr om: … To: To: … Cal l - I nf o: ; app appear ear anceance- i ndex= ex=4



05-BD5031-00 PAGE 9 OF 39

Effectively the phone is saying: “The incoming call from 5551000 is ringing the the user on the fourth call appearance of the line 5551212”. Once the call is answered, then the 200 OK final response from the UAS may also contain a Call-Info header. It is possible that the call may have moved relative appearances by the time it is answer. answer. This is totally dependant on the user interface of the endpoint. SI P/ 2. 0 200 200 OK … Fr om: … To: To: … Cal l - I nf o: ; app appear ear anceance- i ndex= ex=3

Effectively the phone is saying: “The incoming call from 5551000 has been answered by the user on the third call appearance of line 5551212”. If the user interface on the endpoint does not choose a particular call appearance until it answered, then it is possible that the 180 Ringing does not have a Call-Info header and the 200 OK has a Call-Info header. Note that the Call-Info header is not required to be present in responses to a Re-INVITE, but if present, the responses must use the same appearance-index (that is, a Re-INVITE response is not allowed to change the appearance-index being used). When BroadWorks is acting as the UAS, the device must honor the appearance-index included in INVITE responses. In some scenarios (for example, when the device does not perform a line-seize prior to the INVITE and the requested appearance-index is already in use by BroadWorks), BroadWorks will override the requested appearance-index when it responds to the INVITE. In these scenarios, the device should move the call to the appearance-index specified in the response. When the device is acting as the UAS and it receives an INVITE with a requested appearance-index, it must use the same appearance-index for all responses (that is, it is not allowed to change the appearance-index in a response). In a race condition where the device initiates a line-seize for an appearance-index at the same time as BroadWorks sends an INVITE to the device for the same appearance-index, the device should allow the INVITE for the incoming call to proceed. A failure response to the line-seize SUBSCRIBE will be received by the device shortly afterwards in NOTIFY requests. Finally, a notifier can include a Call-Info header when sending a NOTIFY request to a subscriber of the Call-Info event package (description follows). The Call-Info header of a NOTIFY request must contain a complete set of call appearance information elements – one for each potential call-appearance on the the address of record. Each call appearance information element must contain one appearance-index and one appearance-state parameter. Optionally, each call appearance information element can contain one appearance-URI parameter. So the subscriber receives complete call appearance state information for the address of record in each NOTIFY. For example, if the address of record [email protected] has four call appearances allowed, and there is one call active on the first call appearance and one call held on the second call appearance, and the rest of the call appearances are idle, then the following NOTIFY is sent to each subscriber of [email protected] [email protected].. NOTI FY si p: cont cont act @end endpoi poi nt … Fr om: … To: To: … Cal l - I nf o: ; app appear ear anceance- i ndex= ex=1; app appear ear anceancest at e=act i ve; ve; app appear ear anceance- ur i =”\ ”Geo ”Georr ge Smi t h\ ” ”,



05-BD5031-00 PAGE 10 OF 39

; appe appear ar anceance- i ndex= ndex=2; app appear ear anceancest ate=hel d, ; appe appear ar anceance- i ndex= ndex=3; app appear ear anceancest at e=i dl e, ; app appear ear anceance- i ndex= ex=4; app appear ear anceancest at e=i dl e

We can use the “*” as a short-cut to indicate “the rest of the call appearances”, which is useful when initializing the call-appearances for an address of record to “idle”: NOTI FY si p: cont cont act @end endpoi poi nt … Fr om: … To: To: … Cal l - I nf o: ; et>; app appear ear ance ance-- i ndex= ex=*; app appear ear ance ance-- st ate=i dl e

is semantically equivalent to: NOTI FY si p: cont cont act @end endpoi poi nt … Fr om: … To: To: … Cal l - I nf o: ; app appear ear anceance- i ndex= ex=1; app appear ear anceancest at e=i dl e, ; appe appear ar anceance- i ndex= ndex=2; app appear ear anceancest at e=i dl e, ; appe appear ar anceance- i ndex= ndex=3; app appear ear anceancest at e=i dl e, ; app appear ear anceance- i ndex= ex=4; app appear ear anceancest at e=i dl e

2.2.3

In SUBSCRIBE SUBSCRIBE requ ests A subs subscri criber ber MUST MUST inclu include de a Call-Info header with an appearance-index information element in a SUBSCRIBE request to the line-seize event package. The Application Server handling the subscription uses the appearance-index in the Call-Info header to identify which call-appearance the line-seize subscription is being applied to.

2.3 2.3 2.3.1

Call-Info Call-Info “ Answ er-After” Info-parameter Overview To support click to dial and push to talk applications, an application platform must be able to originate calls that force the endpoint off-hook, without end-user intervention. Here we introduce a generic parameter called “answer-after”. When present in the CallInfo header of an incoming INVITE request, it indicates how many alert cycles should be applied by the UAS before the the call is automatically answered. For example, the following Call-Info header indicates that the call should be automatically answered after one alert cycle. I NVI TE si p: 1234 123456 5678 789@ 9@ br oadw oadwor ks. net net SI P/ 2. 0 Fr om: ; t ag= ag=1 To: To: Cal l - I nf o: ; et>; answ answer- af t er=1



05-BD5031-00 PAGE 11 OF 39

If the “answer-after” value is 0, then the call should be automatically answered without applying any alert tones, as shown in the following example. I NVI TE si p: 1234 123456 5678 789 9@broadw broadwor ks. net net SI P/ 2. 0 Fr om: ; t ag= ag=1 To: Cal l - I nf o: ; et>; answ answer - af t er=0 er=0

In all cases, the Call-Info header is just a suggestion to the UAS. Depending on the UAS capabilities or local policy, the UAS may elect to ignore the “answer-after” “answer-after” parameter. For instance, if the UAS is a phone that does not support speakerphone, then it cannot automatically answer the call, and must wait for the user to actively answer the call. Similarly, the phone may have a speakerphone, but the user may have enabled a local privacy policy that rejects or ignores all “answer-after” requests. A UAC should be prepared to receive an 18x provisional response, even when it has requested that the UAS automatically answer the call without alerting (meaning answer-after=0). In all cases, the UAS should attempt to authorize the the incoming request. At minimum, the UAS should perform access control. Ideally, the UAS should challenge the incoming INVITE for credentials that authorize the request to perform an automatic answer. 2.3.2 2.3.2

Example Message Flow The following diagram shows the message flow as a result of the users performing a clickto-dial operation from their thin client interface.

Workstation

IP Phone

Application Server

Terminating Device

[F1] Dial 3015551212 3015551212 [F2] INVITE w/answer-after=0

Figure 1 Message Message Flow as a Result Result of Click-To-Dial Click-To-Dial Operation

[F1] starts the flow with the user initiating a click-to-dial operation from the thin call client on the workstation. workstation. The Application Server processes the click-to-dial event. The Application Server sends an INVITE to the associated endpoint in [F2], as follows: [ F2] F2] I NVI TE Ap Appl i cat cat i on Ser ver ver - > I P ph phone I NVI TE si p: 3015 301555 5510 100 00@i ppho pphone ne.. com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; br anch= anch=m9hG 9hG4bK7 4bK74b 4bff 9 Max- For war ds: 70 Fr om: “J oe” ; t ag= ag=5f xced76 xced76sl sl To: “J ane” Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 511@ 1@a1. a1. f oo. com



05-BD5031-00 PAGE 12 OF 39

Cal l - I nf o: ; app appear ear ance ance-- i ndex= ex=1; answ answer- af t er=0 CSeq: Seq: 4323 43234 4 I NVI TE Cont ont act : > Al l ow- Even vent s: con conf erence erence Al l ow: ACK, BYE, YE, CANCEL, I NFO, I NVI TE, OPTI ONS, PRA PRACK, REFER EFER Support ed: ed: 100r el , t i mer Cont ont ent ent - Leng Lengt h: 0



05-BD5031-00 PAGE 13 OF 39

3

Call-Info Event Package

3.1

Overview The ability to support shared call appearances (SCA) is a fundamental building block for a variety of enhanced telephony services. Features like attendant console, line extensions, and key system emulation cannot be delivered without some mechanism for sharing call appearances across access devices. Although SIP (RFC 3261) by itself offers no inherent semantics for supporting SCA features, when coupled with an appropriate instantiation of the “SIP Specific Event Notification” framework (RFC 3265), these services can be deployed quite easily in a distributed network. A shar shared ed line is an addres address s of of recor record d mana managed ged by centra centrall cont control rolling ling element element,, such such as an application server. The application server allows multiple endpoints to register locations against the address of record. The application server is responsible for policing who can register and who cannot register against the shared line. For incoming call appearances, the application server sends separate INVITE requests to each of the registered endpoints. As the incoming call appearance progresses to the answered state on one of the endpoints, the INVITE requests to the other endpoints in the shared call appearance group are cancelled. For outgoing call appearances, the application server presents any call from the registered endpoints as originating from the same address of record. Effectively, the line is shared because any endpoint in the shared call appearance group can originate and terminate calls on behalf of the same address of record. The following sections describe how the Call-Info header can be used to suggest the presentation state of the call appearances on a shared line. A Call-Info event package can then be used to broadcast this presentation state to endpoints that are not actively involved in the call appearances. The Call-Info event package is an instantiation of the SIP Specific Event Notification Framework (as defined in RFC 3265). For the applications described earlier, the Applicat Application ion Server Server acts acts as as the the “notifi “notifier” er”,, while while the IP phones phones configur configured ed with with shar shared ed lines lines act as the “subscribers”. Following is a description of the event package details, as per RFC 3265.

3.2 3.2.1 3.2.1

Exampl e Message Flow Shared Call App earance Client Subscr ipti on This process allows the endpoint to SUBSCRIBE to the call appearance state of a given line. The Request-URI for these transactions is the same as the Request-URI used in the registration process for the address of record (in this case, a “line”). Note that the call flow does not show the SUBSCRIBE being challenged. The application server may choose to use access control (using the IP address authenticated in the REGISTER transaction), or optionally it could challenge the transaction. If the transaction is challenged, then the IP phone should use the same credentials it used in the corresponding registration process for that call appearance. Throughout the rest of this example, it is assumed that standard access control is being applied to all transactions. After After accept accepting ing the SUBSCR SUBSCRIBE IBE,, the the applica applicatio tion n serv server er initiali initializes zes the phone phone to the appropriate call status by sending a NOTIFY with a call state document. This NOTIFY event is sent even if the call state is idle, and serves as a synchronization event between the application server and the IP phone.



05-BD5031-00 PAGE 14 OF 39

[ F1] F1] SUBSCRI BE A A-- 1 - > Appl i cat cat i on Server erver SUBSCRI BE si p: shar shar eded- a@as. f oo. oo. com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. oo. com: 5060; 060; br anch= anch=dsdf dsdf 32na 32nashd shds7 s7 Max- For war ds: 70 Fr om: “Shar “Shar eded- A” ; t ag= ag=dsa3dszl sa3dszl f l To: “Shar ed- A” Cal l - I D: 5j 9FpLxk FpLxk3 3uxt m8t o@a1. a1. f oo. oo. com CSeq: 6 SUBS SUBSCR CRII BE Event : c al al l - i nf o Expi xpi r es: 3600 Cont ont act : Cont ont ent ent - Leng Lengt h: 0 [ F2] F2] 200 OK Appl i cat i on Server  AA- 1 SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. oo. com: 5060; 060; br anch= anch=dsdf dsdf 32na 32nashd shds7 s7 Fr om: “Shar “Shar eded- A” ; t ag= ag=dsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=3234 323423 2323 233 3 Cal l - I D: 5j 9FpLxk FpLxk3 3uxt m8t n@a1. a1. f oo. oo. com CSeq: 6 SUBS SUBSCR CRII BE Event : c al al l - i nf o Cont ont act act : si p: shared shared-- a@as. f oo. oo. com com Expi xpi r es: 3600 Cont ont ent ent - Leng Lengt h: 0 [ F3] F3] NOTI FY Appl i cat cat i on Se Ser ver ver - > A- 1 NOTI FY si p: shared shared-- a@ a1. a1. f oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Max- For war ds: 70 Fr om: “Shar “Shar eded- A” ; t ag= ag=dsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=3234 323423 2323 233 3 Cal l - I D: 5j 9FpLxk FpLxk3 3uxt m8t n@a1. a1. f oo. oo. com CSeq: 1344 1344 NO NOTI FY Event : c al al l - i nf o Subscr i pt i on- St ate: act act i ve; ve; expi xpi r es=3599 Cont ont act act : si p: shared shared-- a@as. f oo. oo. com com Cal l - I nf o: ; app appear ear ance ance-- i ndex= ex=*; app appear ear ancece- st ate=i dl e Cont ont ent ent - Leng Lengt h: 0 [ F4] 200 200 OK AA- 1  Ap Appl i cat cat i on Ser ver ver SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Fr om: “Shar “Shar eded- A” ; t ag= ag=dsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=3234 323423 2323 233 3 Cal l - I D: 5j 9FpLxk FpLxk3 3uxt m8t n@a1. a1. f oo. oo. com CSeq: 1344 1344 NO NOTI FY Cont ont ent ent - Leng Lengt h: 0



05-BD5031-00 PAGE 15 OF 39

3.2.2 3.2.2

Outgoi ng Call The following figure shows the call flow as a result of endpoint A-1 originating a call to B using A’s shared line. It is assumed that A-1 has successfully seized the line. IP Phone A-1

IP Phone A-2

AS

Phone B

[F1] INVITE [F2]100 Trying [F3] NOTIFY line-seize

Step 4.1: A-1 cal ls B

[F4] 200 OK [F5] INVITE [F6] 180 Ringing [F7] 180 Ringing

[F9] NOTIFY call-info (Progressing)

[F8] NOTIFY call-info (Progressing)

Step 4.2: AS Not ifi es A-1/A-2 t hat call is Progressing

[F10] 200 OK [F11] 200 OK

Step 4.3: B answers call

[F12] 200 OK [F13] 200 OK [F14] ACK [F15] ACK

[F17] NOTIFY call-info (Active)

[F16] NOTIFY call-info (Active) [F18] 200 OK

[F19] 200 OK

Step 4.4: AS no tif ies A-1/A-2 t hat call is now Act ive

Figure 2 Call Flow as a Resu Resultlt of Endpoint A-1 Origi Originating nating a Call to to B using A’s A’s Shared Line



05-BD5031-00 PAGE 16 OF 39

3.2.2.1

A-1 Calls B In [F1 to F7], the user on IP phone A-1 has entered digits that originates a call to B. Because the endpoint has already seized the line, the Application Server accepts the INVITE and simply treats the call like a standard outbound call to an off network device. Note that in [F3], the Application Server sends a NOTIFY-request to A-1, indicating that the line-seize subscription has been terminated. This is normal once an INVITE has been received from the endpoint that has seized the call appearance on the shared line. [ F1] F1] I NVI TE A- 1



Ap Appl i cat cat i on Ser ver ver

I NVI TE si p: B@as. f oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; br anch= anch=m9hG 9hG4bK7 4bK74b 4bff 9 Max- For war ds: 70 Fr om: “Shar “Shar eded- A” ; t ag= ag=5f xced76 xced76sl sl To: “B” Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 511@ 1@a1. a1. f oo. com Cal l - I nf o: ; app appear ear ance ance-- i ndex= ex=1 CSeq: Seq: 4323 43234 4 I NVI TE Cont ont act : Cont ont ent ent - Typ Type: app appl i cat cat i on/ on/ sdp sdp Cont ont ent ent - Lengt Lengt h: 143 v=0 o=User A 2890 289084 8445 4526 26 2890 289084 8445 4526 26 I N I P4 a1. a1. f oo. com s=s=c=I N I P4 192. 192. 0. 2. 101 101 t =0 0 m=audi o 49172 RTP/ RTP/ AVP AVP 0 a=r t pmap: 0 PCMU/ 8000 [ F2] F2] 100 Tryi ng Appl i cat cat i on Server erver



AA- 1

SI P/ 2. 0 10 100 Tryi ng Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; br anch= anch=m9hG 9hG4bK7 4bK74b 4bff 9 Fr om: “Shar “Shar eded- A” ; t ag= ag=5f xced76 xced76sl sl To: “B” ; t ag=4323 4323z39 z39 Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 511@ 1@a1. a1. f oo. com Cal l - I nf o: ; app appear ear ance ance-- i ndex= ex=1 CSeq: Seq: 4323 43234 4 I NVI TE Cont ont act : Cont ont ent ent - Leng Lengt h: 0 [ F3] F3] NOTI FY Appl i cat cat i on Se Ser ver ver - > A- 1 NOTI FY si p: shared shared-- a@ a1. a1. f oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP as. as. f oo. oo. com: 5060; 060; branch= branch=gsdf gsdf 32n 32nashds7 ashds7 Max- For war ds: 70 Fr om: “Shar “Shar eded- A” ; t ag= ag=gsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=4234 423423 2323 233 3 Cal l - I D: 6j 9FpLxk FpLxk3 3uxt m8t o@a1. a1. f oo. oo. com CSeq: 24 NOTI FY Event : l i ne- s ei ei z e Subscr i pt i on- St ate: t ermi nated; ated; exp expi r es=0 Cont ont act act : si p: shared shared-- a@as. f oo. oo. com com Cont ont ent ent - Leng Lengt h: 0 [ F4] 200 200 OK AA- 1  Ap Appl i cat cat i on Ser ver ver SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Fr om: “Shar “Shar eded- A” ; t ag= ag=gsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=4234 423423 2323 233 3 BROADWORKS SIP ACCESS SIDE EXTENSIONS INTERFACE SPECIFICATIONS ©


05-BD5031-00 PAGE 17 OF 39

Cal l - I D: 6j 9FpLxk FpLxk3 3uxt m8t n@a1. a1. f oo. oo. com CSeq: 24 NOTI FY Cont ont ent ent - Leng Lengt h: 0

[ F5] F5] I NVI TE Ap Appl i cat cat i on Se Ser ver ver



B

I NVI TE si p: B@b. f oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP as. as. f oo. oo. com: 5060; br anch anch= =234adf adf r j ksd Max- For war ds: 70 Fr om: “ Shar Shar eded- A” ; t ag= ag=234w 234wdkf j To: “B” Cal l - I D: asdf asdf 2220188511@as. f oo. oo. com CSeq: Seq: 1234 12345 5 I NVI TE Cont ont act : Cont ont ent ent - Typ Type: app appl i cat cat i on/ on/ sdp sdp Cont ont ent ent - Lengt Lengt h: 143 v=0 o=User A 2890 289084 8445 4526 26 2890 289084 8445 4526 26 I N I P4 a1. a1. f oo. com s=s=c=I N I P4 192. 192. 0. 2. 101 101 t =0 0 m=audi o 49172 RTP/ RTP/ AVP AVP 0 a=r t pmap: 0 PCMU/ 8000 [ F6] F6] 180 180 Ri ngi ngi ng B




SI P/ 2. 0 180 Ri ngi ng Vi a: SI P/ 2. 0/ UDP as. as. f oo. oo. com: 5060; br anch anch= =234adf adf r j ksd Fr om: “ Shar Shar eded- A” ; t ag= ag=234w 234wdkf j To: “B” ; t ag=1234 1234dsf dsf 2 Cal l - I D: asdf asdf 2220188511@as. f oo. oo. com CSeq: Seq: 1234 12345 5 I NVI TE Cont ont act : Cont ont ent ent - Leng Lengt h: 0 [ F7] F7] 180 Ri ngi ng Appl i cat cat i on Server erver



AA- 1

SI P/ 2. 0 180 Ri ngi ng Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; br anch= anch=m9hG 9hG4bK7 4bK74b 4bff 9 Fr om: “Shar “Shar eded- A” ; t ag= ag=5f xced76 xced76sl sl To: “B” ; t ag=4323 4323z39 z39 Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 511@ 1@a1. a1. f oo. com Cal l - I nf o: ; app appear ear ance ance-- i ndex= ex=1 CSeq: Seq: 4323 43234 4 I NVI TE Cont ont act : Cont ont ent ent - Leng Lengt h: 0



05-BD5031-00 PAGE 18 OF 39

3.2.2.2

Application Server Notifies A-1 and A-2 that Call is Progressing As the call progres progresses ses,, the the Applicat Application ion Server Server sends sends CallCall-Inf Info o NOTI NOTIFYFY-req reques uests ts to all endpoints that have subscribed to the Call-Info event package on the shared line. In this example, IP phones A-1 and A-2 have both subscribed to the Call-Info event package, so the Application Server sends a NOTIFY-request to both A-1 and A-2, with a Call-Info header indicating a state of “Progressing” (events [F8-F11]). [ F8] F8] NOTI FY Appl i cat cat i on Se Ser ver ver - > A- 1 NOTI FY si p: shared shared-- a@ a1. a1. f oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Max- For war ds: 70 Fr om: “Shar “Shar eded- A” ; t ag= ag=dsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=3234 323423 2323 233 3 Cal l - I D: 5j 9FpLxk FpLxk3 3uxt m8t n@a1. a1. f oo. oo. com CSeq: 1344 1344 NO NOTI FY Event : c al al l - i nf o Subscr i pt i on- St ate: act act i ve; ve; expi xpi r es=3200 Cal l - I nf o: ; app appear ear anceance- i ndex= ex=1; app appear ear anceancest ate=pr ogr essi ng, ; app appear ear anceance- i ndex= ex=*; app appear ear anceancest at e=i dl e Cont ont ent ent - Leng Lengt h: 0 [ F9] F9] NOTI FY Appl i cat cat i on Se Ser ver ver - > A- 2 NOTI FY si p: shared shared-- a@ a2. a2. f oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Max- For war ds: 70 Fr om: “Shar “Shar eded- A” ; t ag= ag=ggsa3d gsa3dsz l f l To: “Shar ed- A” ; t ag=1234 123456 56 Cal l - I D: 9k9Fp k9FpLxk Lxk3 3uxt m8t n@a2. a2. f oo. oo. com CSeq: 1345 1345 NO NOTI FY Event : c al al l - i nf o Subscr i pt i on- St ate: act act i ve; ve; expi xpi r es=3100 Cal l - I nf o: ; app appear ear anceance- i ndex= ex=1; app appear ear anceancest ate=pr ogr essi ng, ; app appear ear anceance- i ndex= ex=*; app appear ear anceancest at e=i dl e Cont ont ent ent - Leng Lengt h: 0 [ F10] 200 200 OK AA- 1  Ap Appl i cat cat i on Ser ver ver SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Fr om: “Shar “Shar eded- A” ; t ag= ag=dsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=3234 323423 2323 233 3 Cal l - I D: 5j 9FpLxk FpLxk3 3uxt m8t n@a1. a1. f oo. oo. com CSeq: 1344 1344 NO NOTI FY Cont ont ent ent - Leng Lengt h: 0 [ F11] 200 200 OK AA- 2  Ap Appl i cat cat i on Ser ver ver SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Fr om: “Shar “Shar eded- A” ; t ag= ag=ggsa3d gsa3dsz l f l To: “Shar ed- A” ; t ag=1234 123456 56 Cal l - I D: 9k9Fp k9FpLxk Lxk3 3uxt m8t n@a2. a2. f oo. oo. com CSeq: 1345 1345 NO NOTI FY Cont ont ent ent - Leng Lengt h: 0



05-BD5031-00 PAGE 19 OF 39

3.2.2.3

B Answers Call [F12 to F15] shows B answering the call using standard back-to-back user agent call flow. A-1 and B are are now active active in a call. call. [ F12] 200 OK B




SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP as. as. f oo. oo. com: 5060; br anch anch= =234adf adf r j ksd Fr om: “ Shar Shar eded- A” ; t ag= ag=234w 234wdkf j To: “B” ; t ag=1234 1234dsf dsf 2 Cal l - I D: asdf asdf 2220188511@as. f oo. oo. com CSeq: Seq: 1234 12345 5 I NVI TE Cont ont act : Cont ont ent ent - Leng Lengt h: 0 [ F13 F13] 200 OK Appl i cat i on Server



AA- 1

SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; br anch= anch=m9hG 9hG4bK7 4bK74b 4bff 9 Fr om: “Shar “Shar eded- A” ; t ag= ag=5f xced76 xced76sl sl To: “B” ; t ag=4323 4323z39 z39 Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 511@ 1@a1. a1. f oo. com Cal l - I nf o: ; app appear ear ance ance-- i ndex= ex=1 CSeq: Seq: 4323 43234 4 I NVI TE Cont ont act : Cont ont ent ent - Leng Lengt h: 0 [ F14] F14] ACK A- 1




ACK si p: B@as. f oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. oo. com: 5060; 060; br anch= anch=345rbK 345rbK74 74bf bf 9 Max- For war ds: 70 Fr om: “ Shar Shar eded- A” ; t ag= ag=234w 234wdkf j To: “B” ; t ag=1234 1234dsf dsf 2 Cal l - I D: asdf asdf 2220188511@f oo. oo. com CSeq: 1093 ACK ACK Cont ont act : Cont ont ent ent - Leng Lengt h: 0 [ F15 F15] ACK Appl i cat i on Server



B

ACK si p: B@b. f oo. oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=23dsd 23dsdff 2ksd 2ksd Max- For war ds: 70 Fr om: “ Shar Shar eded- A” ; t ag= ag=234w 234wdkf j To: “B” ; t ag=1234 1234dsf dsf 2 Cal l - I D: asdf asdf 2220188511@f oo. oo. com CSeq: 12345 ACK ACK Cont ont act : Cont ont ent ent - Leng Lengt h: 0



05-BD5031-00 PAGE 20 OF 39

3.2.2.4

Application Server Notifies A-1 and A-2 that Call is Now Now Active In [F16 to F19] the Application Server sends a NOTIFY-request to IP phones A-1 and A-2 with a Call-Info header, indicating a call appearance state of “Active” for the first call appearance on the shared line. [ F16 F16] NOTI FY Appl i cat cat i on Server erver - > A- 1 NOTI FY si p: shared shared-- a@ a1. a1. f oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Max- For war ds: 70 Fr om: “Shar “Shar eded- A” ; t ag= ag=dsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=3234 323423 2323 233 3 Cal l - I D: 5j 9FpLxk FpLxk3 3uxt m8t n@a1. a1. f oo. oo. com CSeq: 1344 1344 NO NOTI FY Event : c al al l - i nf o Subscr i pt i on- St ate: act act i ve; ve; expi xpi r es=3000 Cal l - I nf o: ; app appear ear ance ance-- i ndex= ex=1; app appear ear ancece- st ate=act act i ve, ve, ; app appear ear anceance- i ndex= ex=*; app appear ear anceancest at e=i dl e Cont ont ent ent - Leng Lengt h: 0 [ F17 F17] NOTI FY Appl i cat cat i on Server erver - > A- 2 NOTI FY si p: shared shared-- a@ a2. a2. f oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Max- For war ds: 70 Fr om: “Shar “Shar eded- A” ; t ag= ag=ggsa3d gsa3dsz l f l To: “Shar ed- A” ; t ag=1234 123456 56 Cal l - I D: 9k9Fp k9FpLxk Lxk3 3uxt m8t n@a2. a2. f oo. oo. com CSeq: 1345 1345 NO NOTI FY Event : c al al l - i nf o Subscr i pt i on- St ate: act act i ve; ve; expi xpi r es=2999 Cal l - I nf o: ; app appear ear ance ance-- i ndex= ex=1; app appear ear ancece- st ate=act act i ve, ve, ; app appear ear anceance- i ndex= ex=*; app appear ear anceancest at e=i dl e Cont ont ent ent - Leng Lengt h: 0 [ F18] 200 200 OK AA- 1  Ap Appl i cat cat i on Ser ver ver SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Fr om: “Shar “Shar eded- A” ; t ag= ag=dsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=3234 323423 2323 233 3 Cal l - I D: 5j 9FpLxk FpLxk3 3uxt m8t n@a1. a1. f oo. oo. com CSeq: 1344 1344 NO NOTI FY Cont ont ent ent - Leng Lengt h: 0 [ F19] 200 200 OK AA- 2  Ap Appl i cat cat i on Ser ver ver SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Fr om: “Shar “Shar eded- A” ; t ag= ag=ggsa3d gsa3dsz l f l To: “Shar ed- A” ; t ag=1234 123456 56 Cal l - I D: 9k9Fp k9FpLxk Lxk3 3uxt m8t n@a2. a2. f oo. oo. com CSeq: 1345 1345 NO NOTI FY Cont ont ent ent - Leng Lengt h: 0

3.3

Event Package Name The name of this event is “Call-Info”. It is carried in the Event and Allow-Events header as defined in RFC 3265.



05-BD5031-00 PAGE 21 OF 39

3.4

Event Package Parameters This package does not define any event package parameters.

3.5

SUBSCRIBE SUBSCRIBE Bod ies A SUBS SUBSCRI CRIBE BE for a Call-Info package must not contain a body. A body is not required for for this application of the Call-Info event package – any body sent in a SUBSCRIBE is ignored by the notifier.

3.6 3.6

Subscr ipti on Duration Subscribers SHOULD specify the duration of a subscription with an Expires header in the SUBSCRIBE request. It is recommended that the subscription use the same refresh refresh period as the REGISTER event. If the notifier changes the expiration period to a lower value (via an Expires header in the final response), the subscriber should honor it. If the subscriber does not specify the duration of a subscription, then the notifier chooses a default expiration. The recommended default is 1800 seconds.

3.7

NOTIFY NOTIFY Bo dies A NOTI NOTIFY FY for a Call-Info package MUST NOT contain a body. No body is required for the Call-Info event package as all state is reflected through the Call-Info header.

3.8 3.8

Subscr iber Generation Generation of SUBSCR SUBSCRIBE IBE Requests Requests Subscriber generation of SUBSCRIBE requests MUST follow all rules with respect to subscriber behavior as described in RFC 3265. For this application, SIP phones that are configured with shared lines should generate SUBSCRIBE requests immediately after successfully registering a location against the provisioned address of record. The Request-URI, From, and To header must be the same as the address of record of the shared line.

3.9 3.9

Notifi er Processin g of SUBSCRI SUBSCRIBE BE Requests Requests Notifier processing of SUBSCRIBE requests MUST follow all rules with respect to notifier behavior as described in RFC 3265. The Call-Info package contains potentially sensitive information. Subscriptions SHOULD be authorized by the notifier. The notifier MAY perform implicit authorization by looking at the source IP address of the SUBSCRIBE event and matching it to any endpoints that have successfully been authenticated through the registration process. The notifier MAY choose to explicitly challenge the subscriber for authentication by using a “401 Unauthorized” response. If the subscriber has also registered a location for this address of record, then it SHOULD use the same credentials to answer the subscription challenge.

3.10 3.10 Noti fi er Generation of NOTIF NOTIFY Y Request s Notifier generation of NOTIFY requests MUST follow all rules with respect to notifier behavior as described in RFC 3265. Notifications are generated for the Call-Info package whenever the supplementary call information associated with an address of record (in this case a line) changes. As described in RFC-3261, supplementary call information can be almost anything. For the purposes of tthese hese applications, the call information includes a complete list of all the call appearances allowed on the address of record and the state of each call appearance. The notifier sends this information in a NOTIFY request by explicitly including a Call-Info header in addition to the required NOTIFY request headers. BROADWORKS SIP ACCESS SIDE EXTENSIONS INTERFACE SPECIFICATIONS ©


05-BD5031-00 PAGE 22 OF 39

See the sections above for details about the content of the Call-Info header and how it should be used.

3.11 3.11 Subscr iber Process Process ing of NOTIF NOTIFY Y Requests Requests In general, subscriber processing of NOTIFY requests MUST follow all rules with respect to subscriber behavior, as described in RFC 3265. The SIP Specific Event Notification Notification Framework expects packages to specify how a subscriber processes NOTIFY requests, and in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. To be specific, the Call-Info package itself has no state, but in this application, the state of the call appearances of a given address of record can be derived from the content of the Call-Info header that is delivered in the NOTIFY request. This state is described in detailed in the following sections. Because these applications use the content of the NOTIFY’s Call-Info header to visually present the call appearance state to the user, the subscriber (that is, the phone) SHOULD perform some level of authorization before processing NOTIFY’s. The subscriber MAY perform implicit authorization by looking at the source IP address of the NOTIFY request event and matching it to any one of the IP addresses of the notifier, as resolved through DNS. The subscriber MAY perform explicit authentication by challenging the notifier, by using a “401 Unauthorized” response. If the subscriber has also registered a location for this address of record, then the notifier SHOULD use those same credentials to answer the notification challenge.

3.12 3.12 Handli Handli ng of Forked Requests Althoug Although h itit is is theo theoret retical ically ly possible possible for a SUBS SUBSCR CRIBE IBE reques requestt to to fork, fork, this this is not likely likely for the applications described in this document. Robust subscriber implementations SHOULD be prepared to install multiple Call-Info subscriptions, but practically speaking, this never happens.

3.13 3.13 Rate of Notifi cations A very very active active phone phone line may result result in many many notif notificat ications ions sent sent to to ever every y endpo endpoint int in the shared call appearance group. Endpoints should be prepared to accept NOTIFY requests as frequently as a few times per second in burst scenarios (which should be infrequent).



05-BD5031-00 PAGE 23 OF 39

4

4.1

Lin e-Seize e-Seize Event Package

Overview SIP has been employed as a line side access protocol in voice networks. When compared to other line side access protocols like SCCP or MGCP, SIP is considered a “peer to peer” protocol. protocol. Because of this, SIP-UAs embedded in IP phones typically provide local dial tone, digit collection, and essentially perform their own line side call setup. This works well for lines that are private to the endpoint. But this behavior can cause race conditions when emulating shared line functionality across multiple endpoints. Emulating shared line functionality requires some central line controller to arbitrate which endpoint has “seized” the line. The purpose of the “line-seize” event package is to support the concept of a line-seizure between an endpoint and line-controller, as found in a typical “shared line” solution. The approach defined here requires that all endpoints that participate in a shared line obtain a subscription to the line-seize package for the shared line before presenting the user with dial tone or collecting digits. This means the endpoints must send a SUBSCRIBE-request for the line-seize event package whenever a user attempts to take the shared line off hook. The “line controller” guarantees that only one subscription to the line-seize event package can exist for a given shared line resource. When the line controller grants a subscription to the line-seize package, it responds to the SUBSCRIBE with a 200 OK response and generates a NOTIFY, indicating that the subscription state is now “active”. This is an indicator to the endpoint that it can safely play dial tone to the user and collect digits. Once the digits have been collected, then the endpoint can send an INVITE-request. While one endpoint has obtained the the line-seize subscription, any requests from other endpoints to use that shared line are rejected with a 480 Temporarily Unavailable response. The line-seize event package is an instantiation of the SIP Specific Event Notification Framework (as defined in RFC 3265). Following is a description of the event package details, as per RFC 3265. To avoid scenarios where the endpoint seizes the line, but never actually uses it (that is, it never sends an INVITE-request) and effectively hangs the line - the line-seize package must have a suitable duration associated with it. Fortunately, the SIP specific event notification framework, as defined in RFC 3265, explicitly describes a mechanism for negotiating subscription duration between the subscriber (the endpoint) and the notifier (the line controller). The SUBSCRIBE-request to to the line-seize package contains an expiration time as offered by the endpoint – and in response the line-controller can choose to set a smaller expiration time. time. If the endpoint has not collected digits and sent an INVITE-request before the subscription has expired, then it must refresh the subscription or risk losing it to another endpoint. Endpoints should only collect digits for a suitable length of time before they they let the subscription expire naturally. This avoids scenarios where one endpoint in the shared call appearance group goes off hook accidentally and effectively ties up the line. After a reasonable amount of time, the endpoint should stop refreshing the subscription, let it expire naturally, and then apply an appropriate local treatment (re-order tone), so the end user is aware that digits can no longer being collected. If the user goes on hook before digit collection is complete – effectively terminating the line seizure without originating a call – then the endpoint must clear the line seizure by explicitly canceling the subscription. This allows the line to be immediately seized by another endpoint. As per RFC 3261, this is effectively achieved by refreshing the the subscription with an expiration of “0”.



05-BD5031-00 PAGE 24 OF 39

4.2 4.2

Example Message Flows The following figure shows the call flow as a result of a user at A-1 taking the shared line off hook. The line controller in this scenario is provided provided by a central Application Server (AS). IP Phone A-1

IP Phone A-2

AS

[F1] SUBSCRIBE line-sieze [F2] 200 OK

Phone B

Step 3.1: A-1 goes o ff hook

[F3] NOTIFY line-seize [F4] 200 OK

[F7] NOTIFY NOTIFY call-inf o (Seized)

[F5] NOTIFY NOTIFY call-inf o (Seized) [F6] 200 OK

[F8] 200 OK

[F9] SUBSCRIBE line-si eze [F10] 200 OK

Step 3.2: AS Noti fies A-1/A-2 that line is Seized

Step 3.3: A-1 refres hes line-seize subscription

[F11] NOTIFY line-seize [F12] 200 OK

Figure 3 Call Flow as a Resu Resultlt of a User at A-1 Taking Taking the Shared Line Off Hook

In [F1 to F4], IP-phone A-1 must be granted a subscription to the line-seize package. Only after the subscription has been granted, should the IP phone play dial tone to the user. [ F1] F1] SUBSCRI BE A A-- 1 - > Appl i cat cat i on Server erver SUBSCRI BE si p: shar shar eded- a@as. f oo. oo. com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 Max- For war ds: 70 Fr om: “Shar “Shar eded- A” ; t ag= ag=gsa3dszl sa3dszl f l To: “Shar ed- A” Cal l - I D: 6j 9FpLxk FpLxk3 3uxt m8t o@a1. a1. f oo. oo. com Cal l - I nf o: ; app appearance arance-- i ndex= ex=1 CSeq: 7 SUBS SUBSCR CRII BE Event : l i ne- s ei ei z e Expi xpi r es: 15 Cont ont act : Cont ont ent ent - Leng Lengt h: 0 [ F2] F2] 200 OK Appl i cat i on Server  AA- 1 SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. oo. com: 5060; 060; br anch= anch=gsdf gsdf 32na 32nashd shds7 s7 BROADWORKS SIP ACCESS SIDE EXTENSIONS INTERFACE SPECIFICATIONS ©


05-BD5031-00 PAGE 25 OF 39

Fr om: “Shar “Shar eded- A” ; t ag= ag=gsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=4234 423423 2323 233 3 Cal l - I D: 6j 9FpLxk FpLxk3 3uxt m8t n@a1. a1. f oo. oo. com CSeq: 7 SUBS SUBSCR CRII BE Cont ont act act : si p: shared shared-- a@as. f oo. oo. com com Event : l i ne- s ei ei z e Expi Expi r es=15 Cont ont ent ent - Leng Lengt h: 0 [ F3] F3] NOTI FY Appl i cat cat i on Se Ser ver ver - > A- 1 NOTI FY si p: shared shared-- a@ a1. a1. f oo. com com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP as. f oo. oo. com: 5060; br anch anch= =gf asdf asdf 237 Max- For war ds: 70 Fr om: “Shar “Shar eded- A” ; t ag= ag=gsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=4234 423423 2323 233 3 Cal l - I D: 6j 9FpLxk FpLxk3 3uxt m8t o@a1. a1. f oo. oo. com Cal l - I nf o: ; app appearance arance-- i ndex= ex=1 CSeq: Seq: 9 NO NOTI FY Event : l i ne- s ei ei z e Subscri pt i on- St at e: acti ve; 14 Cont ont act act : si p: shared shared-- a@as. f oo. oo. com com Cont ont ent ent - Leng Lengt h: 0 [ F4] 200 200 OK AA- 1  Ap Appl i cat cat i on Ser ver ver SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. oo. com: 5060; br anch anch= =gf asdf asdf 237 Fr om: “Shar “Shar eded- A” ; t ag= ag=gsa3dszl sa3dszl f l To: “Shar ed- A” ; t ag=4234 423423 2323 233 3 Cal l - I D: 6j 9FpLxk FpLxk3 3uxt m8t n@a1. a1. f oo. oo. com CSeq: Seq: 9 NO NOTI FY Cont ont ent ent - Leng Lengt h: 0

4.3

Event Package Name The name of this event package is “line-seize”. It is carried in the Event and Allow-Events header as defined in RFC 3265.

4.4

Event Package Parameters This package does not define any event package parameters.

4.5

SUBSCRIBE SUBSCRIBE Bod ies A SUBS SUBSCRI CRIBE BE for a line-seize package MUST NOT contain a body. No body is required for this application of the line-seize event package – any body sent in a SUBSCRIBE is ignored by the notifier.

4.6 4.6

Subscr ipti on Duration Subscribers SHOULD specify the duration of a subscription with an Expires header in the SUBSCRIBE request. It is recommended that the subscription use a refresh period, equal roughly to how long it takes for a typical end user to dial a full E.164 number. If the notifier changes the expiration period to a lower value (via an Expires header in the final response), the subscriber should honor it. If the subscriber does not specify the duration of a subscription, then the notifier chooses a default expiration value. The recommended default default is 15 seconds.



05-BD5031-00 PAGE 26 OF 39

4.7

NOTIFY NOTIFY Bo dies A NOTI NOTIFY FY for a line-seize package MUST NOT contain a body. No body is required for the line-seize event package, as it uses a very simple state machine of either active or terminated – which is easily reflected through the Subscription-State header. A body contained in a NOTIFY-request should be ignored by the subscriber.

4.8 4.8

Subscr iber Generation Generation of SUBSCR SUBSCRIBE IBE Requests Requests Subscriber generation of SUBSCRIBE requests MUST follow all rules with respect to subscriber behavior, as described in RFC 3265. Typically, SIP phones that are configured with shared lines should generate SUBSCRIBE requests immediately after a user’s attempts to go off hook on an idle shared line. The Request-URI, From, and To header must be the same as the address of record of the shared line.

4.9 4.9

Notifi er Processin g of SUBSCRI SUBSCRIBE BE Requests Requests Notifier processing of SUBSCRIBE requests MUST follow all rules with respect to notifier behavior, as described in RFC 3265. The line-seize package contains potentially sensitive information. Subscriptions SHOULD be authorized by the notifier. The notifier MAY perform implicit authorization by looking at the source IP address of the SUBSCRIBE event and matching it to any endpoints that have successfully been authenticated through the registration process. The notifier MAY choose to explicitly challenge the subscriber for authentication, by using a “401 Unauthorized” Unauthorized” response. If the subscriber has also registered a location for this address of record, then it SHOULD use the same credentials to answer the subscription challenge.

4.10 4.10 Noti fi er Generation of NOTIF NOTIFY Y Request s Notifier generation of NOTIFY requests MUST follow all rules with respect to notifier behavior, as described in RFC 3265. Notifications are generated for the line-seize package immediately after a subscription has been accepted.

4.11 4.11 Subscr iber Process Process ing of NOTIF NOTIFY Y Requests Requests In general, subscriber processing of NOTIFY requests MUST follow all rules with respect to subscriber behavior, as described in RFC 3265. The SIP Specific Event Notification Notification framework expects packages to specify how a subscriber processes NOTIFY requests, and in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. The line-seize package has binary state. Either the “line-seize” subscription is active or it’s terminated. This state is reflected in the Subscription-State header. The endpoint SHOULD perform some level of authorization before processing NOTIFYs. NOTIFYs. The subscriber MAY perform implicit authorization by looking at the source IP address of the NOTIFY request event and matching it to any one of the known IP addresses of the notifier (in this case the Application Server), as resolved through DNS. The subscriber MAY perform explicit authentication by challenging the notifier, by using a “401 Unauthorized” response. If the subscriber has also registered a location for this this address of record, then the notifier SHOULD use those same credentials to answer the notification challenge.



05-BD5031-00 PAGE 27 OF 39

4.12 4.12 Handli Handli ng of Forked Requests Althoug Although h itit is is theo theoret retical ically ly possible possible for a SUBS SUBSCR CRIBE IBE reques requestt to to fork, fork, this this is not likely likely for typical applications that use the line-seize event package. Since the nature of the subscription guarantees that only one subscription exist at a time, then the first forked request that arrives at the Application Server is granted a subscription, while the rest of the SUBSCRIBE-requests are rejected.

4.13 4.13 Rate of Notifi cations Notifications are only sent when the endpoint explicitly refreshes the subscription (about every 15 seconds), when the subscription expires (also after about 15 seconds), or when the subscription is terminated.



05-BD5031-00 PAGE 28 OF 39

5

5.1

Remot Remot e Contro l Talk Event Package Package

Overview When providing CTI based applications such as desktop call control clients, a service delivery platform must be able to request that an endpoint answer an incoming call. This extension provides the ability for an Application Server to send an asynchronous NOTIFY event to an endpoint, using an existing INVITE dialog. When received, the endpoint can elect to honor the request and answer the call, without local user intervention. This extension can also be used to support remotely retrieving a call that has been previously held. When the endpoint receives the NOTIFY NOTIFY event and the associated dialog is in the held state, then the endpoint can elect to honor the request and retrieve the call from the held state. The “talk” event package is an instantiation of the SIP Specific Event Notification Framework (as defined in RFC 3265). Following are details of the event package, as per RFC 3265.

5.2

Exampl e Message Flow The following diagram shows the call flow as a result of a user performing a click-toanswer function on an incoming call from the PSTN.

Workstation

Application Server

IP Phone

Media Server

Network Gateway

[F1] INVITE w/SDP offer [F2] INVITE w/SDP offer

[F3] Incoming

[F4] 180 Ringing [F5] 180 Ringing [F6] Talk

[F7] NOTIFY Event: answer

[F8] 200 OK (Notify)

[F9] 200 OK (Invite) w/SDP answer

[F10] Talking [F11] 200 OK OK w/SDP answer [F12] ACK [F13 ACK

Two-way voice path established.

Figure 4 Click-To-Answer Call Flow



05-BD5031-00 PAGE 29 OF 39

The call arrives at the Application Server in [F1] as usual. The Application Server sends an INVITE to the IP phone registered against the user profile in [F2]. [ F2] F2] I NVI TE Ap Appl i cat cat i on Ser ver ver - > I P ph phone I NVI TE si p: 3015 301555 5510 100 00@i ppho pphone ne.. com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; br anch= anch=m9hG 9hG4bK7 4bK74b 4bff 9 Max- For war ds: 70 Fr om: “J oe” ; t ag=5f xced76s2 xced76s2 To: “J ane” Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 512@ 2@a1. a1. f oo. com Cal l - I nf o: ; app appear ear ance ance-- i ndex= ex=1 CSeq: Seq: 4323 43234 4 I NVI TE Cont ont act : > Al l ow: ACK, BYE, YE, CANCEL, I NFO, I NVI TE, OPTI ONS, PRA PRACK, REFER EFER Support ed: ed: 100r el , t i mer Cont ont ent ent - Typ Type: app appl i cat cat i on/ sdp sdp Cont ont ent ent - Lengt Lengt h: 192 v=0 o=f oo- UA 5184 5184 1464 14642 2 I N I P4 net wor kgat eway. com s=SI P Cal l c=I N I P4 net net wor kgat kgat eway. com t =0 0 m=audi o 27192 RTP/ AVP AVP 0 8 18 a=r t pmap : 0 PCMU/ 8000 a=r t pmap : 8 PCMA/ 8000 a=r t pmap: 10 G729 G729// 0000 0000

At about about the the same same time time,, the the Applica Application tion Server Server sends sends a notifi notificat cation ion [F3] [F3] to to the the call client client on the workstation, indicating that a call has arrived. The call client presents this to the end user. At about the same time as the user sees the call client present the incoming call on the desktop, the phone on his/her desk starts to alert and the phone responds to the INVITE with a 180 Ringing in [F4]. [ F4] F4] SI P/ 2. 0 180 Ri ngi ng Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; br anch= anch=m9hG 9hG4bK7 4bK74b 4bff 9 Fr om: “J oe” ; t ag=5f xced76s2 xced76s2 To: “J ane” ; t ag=763j 763j xd879 xd879sa sa Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 512@ 2@a1. a1. f oo. com Cal l - I nf o: ; app appear ear ance ance-- i ndex= ex=1 CSeq: Seq: 4323 43234 4 I NVI TE Cont act : > Al l ow- Event s: hol d, t al k Cont ont ent ent - Leng Lengt h: 0

Allow-Eve Events nts The 180 Ringing progress is passed on to the network gateway in [F5]. The Allowheader in the 180 Ringing indicates to the Application Server that this endpoint supports remote call control primitives. When the user selects the incoming call and clicks on “talk” – an an event event is sent sent from from the call client client to the Applicat Application ion Server Server in [F6], [F6], indicat indicating ing that that the the user is requesting that the the incoming call be answered. The Application Server reacts by sending a NOTIFY to the SIP phone in [F7]. [ F7] F7] NOTI FY Appl i cat cat i on Server erver - > I P Ph Phone one NOTI FY si p: 3015 301555 5510 100 00@i ppho pphone ne.. com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; br anch= anch=m9hG 9hG4bK7 4bK74b 4bff 9 Fr om: “J oe” ; t ag=5f xced76s2 xced76s2 To: “J ane” ; t ag=432d 432d33 33 Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 512@ 2@a1. a1. f oo. com CSeq: 434 NOTI FY Cont ont act : > Event : t al k BROADWORKS SIP ACCESS SIDE EXTENSIONS INTERFACE SPECIFICATIONS ©


05-BD5031-00 PAGE 30 OF 39

Subscri pt i on- St at e: acti ve Cont ont act : > Cont ont ent ent - Leng Lengt h: 0

The IP phone indicates that it honors the request by responding to the NOTIFY with a 200 OK.

NOTE:

For brevity, the authorization procedure is not shown in the figure. Thephone should should always always challenge an incoming NOTIFY NOTIFYfor credentials credentials that authorize the notifier notifier to perform perform remote call control.

[ F8] F8] 200 OK I P Ph Phone one - > Appl i cat cat i on Server erver SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; bran br anch= ch=m9hG 9hG4bK7 4bK74b 4bff 9 Fr om: “ J oe” ; t ag=5f xced76s2 xced76s2 To: To: “J ane” ane” ; t ag= ag=432d 432d33 33 Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 512@ 2@ a1. a1. f oo. com CSeq: 434 NOTI FY Cont ont act act : Cont ont ent ent - Leng Lengt h: 0

The phone then automatically answers the incoming call by forcing off-hook and activating the speaker.

5.3

Event Package Names The event package name is called “talk”. It is carried in the Event and Allow-Events header as defined in RFC 3265.

5.4

Event Package Parameters This event package does not define any event package parameters.

5.5

SUBSCRIBE SUBSCRIBE Bod ies The talk event package does not support dynamic subscriptions through SUBSCRIBE requests.

5.6 5.6

Subscr ipti on Duration Subscriptions are implied by sessions established through INVITE requests and last throughout the duration of the session. When a UAC sends an INVITE to a UAS, it adds Allow-Ev -Event ents s header to the request, indicating all of the event packages it supports. an Allow This implicitly creates the subscription between the UAC and the UAS. When a UAS responds to the INVITE with an 18x provisional response or a 200 OK response, it adds Allow-Ev -Event ents s header indicating all of the event packages it supports. This implicitly an Allow creates the subscription between the UAS and the UAC. These subscriptions last until the session has been terminated with a BYE or CANCEL transaction.



05-BD5031-00 PAGE 31 OF 39

5.7

NOTIFY NOTIFY Bo dies A NOTI NOTIFY FY for a talk package MUST NOT contain a body. No body is required for the talk event package as they have trivial state.

5.8 5.8

Subscr iber Generation Generation of SUBSCR SUBSCRIBE IBE Requests Requests Subscribers should not generate SUBSCRIBE requests. Subscriptions are granted to subscribers implicitly by the establishment of sessions between two user agents.

5.9 5.9

Notifi er Processin g of SUBSCRI SUBSCRIBE BE Requests Requests Notifiers should not process SUBSCRIBE SUBSCRIBE requests. If received, they should be rejected.

5.10 5.10 Subscr iber Process Process ing of NOTIF NOTIFY Y Requests Requests In general, subscriber processing of NOTIFY requests MUST follow all rules with respect to subscriber behavior, as described in RFC 3265. The SIP Specific Event Notification framework expects packages to specify how a subscriber processes NOTIFY requests and, in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. Because these event notifications have the ability to remotely control the user’s handset behavior, the subscriber (for example, the phone) SHOULD perform some level of authorization before processing NOTIFYs. The subscriber MAY perform implicit authorization by looking at the source IP address of the NOTIFY request event and matching it to any one of the IP addresses of the notifier (in this case, the Application Server) as resolved through DNS. The subscriber MAY perform explicit authentication by challenging the notifier, by using a “401 Unauthorized” response. If the subscriber has also registered a location for this address of record, then the notifier SHOULD use those same credentials to answer the notification challenge. When a subscriber receives a talk event notification for a particular dialog, it must apply the “talk” action to the local session in progress. If the session is in the alerting state, then the subscriber should attempt to answer the session, by forcing the call off hook and turning on the speakerphone (if supported). If the session is in the held state, then the subscriber should attempt to retrieve the call. If the subscriber receives a talk notification for a session that is not either in the alerting state or the held state, then the talk notification should be rejected. Note that the subscriber should always respond to the NOTIFY transaction if it was received and before the action is complete. A 200 OK response to a NOTIFY transaction only indicates that the notification has been received, and not that any action associated with the notification was successfully completed.

5.11 5.11 Handli Handli ng of Forked Requests NOTIFYs should not be forked.

5.12 5.12 Rate of Notifi cations The rate of notifications is dictated by the end-user interface on the call control client and can vary from application to application. Endpoints should be prepared to accept NOTIFY NOTIFY requests as frequently as once every two or three seconds.



05-BD5031-00 PAGE 32 OF 39

5.13 5.13 Noti fi er Generation of NOTIF NOTIFY Y Request s Notifications are generated for the talk package whenever a remote call control application requests that an alerting session be answered, or a held session be retrieved. Notifiers should not generate a talk event notification for a session that is already active and streaming media.



05-BD5031-00 PAGE 33 OF 39

6

6.1

Remot Remot e Contro l Hold Event Package Package

Overview When providing CTI based applications such as desktop call control clients, a service delivery platform must be able to remotely request that an endpoint put a call on hold. This extension provides the ability for an Application Server to send an asynchronous NOTIFY event to an endpoint using an existing INVITE dialog. When received, the endpoint can elect to honor the request and put a call on hold, without local user intervention. The “hold” event package is an instantiation of the SIP Specific Event Notification Framework (as defined in RFC 3265). Following is a description of the event package, as per RFC 3265.

6.2

Exampl e Message Flow The following diagram shows the call flow as a result of a user performing a click-to-hold function on an active call from the PSTN.



05-BD5031-00 PAGE 34 OF 39

Workstation

Application Server

IP Phone

Media Server

Network Gateway

[F1] INVITE w/SDP offer [F2] INVITE w/SDP offer

[F3] Incoming

[F4] 180 Ringing [F5] 180 Ringing [F6] 200 OK (Invite) w/SDP answer

[F7] Talking [F8] 200 OK OK w/SDP answer

[F9] ACK [F10] ACK

Two-way voice path established. [F11] Hold [F12] NOTIFY Event: hold

[F13] 200 OK (Notify)

[F14] INVITE w/hold SDP [F15] INVITE w/hold SDP [F16] Held [F17] 200 OK w/hold SDP [F18] 200 OK w/hold SDP

[F19] ACK [F20] ACK

Figure 5 Click-To-Hold Call Flow

The call is set up as usual in [F1-F10] and a two-way audio is established. Now in [F11] the user at the call client decides to remotely hold the call and sends a “hold” request to the Application Server. The Application Server discovered that the endpoint supported supported the hold event package through an Allow Allow-Eve Events nts header in the 180 Ringing provisional response at [F4]. The Application Server reacts by sending a NOTIFY with a hold event event in [F12]. Note that this NOTIFY is sent using the same dialog as the session it is acting on. [ F12 F12] NOTI FY Appl i cat cat i on Server erver - > I P p ph hone one NOTI FY si p: 3015 301555 5510 1000 00@ @i ppho pphone ne.. com SI P/ 2. 0 Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; bran br anch= ch=m9hG 9hG4bK7 4bK74b 4bff 9 Fr om: “ J oe” ; t ag=5f xced76s2 xced76s2



05-BD5031-00 PAGE 35 OF 39

To: To: “J ane” ane” ; t ag= ag=432d 432d33 33 Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 512@ 2@ a1. a1. f oo. com CSeq: 444 NOTI FY Cont ont act act : Even vent : hol d Subscri pt i on- St at e: acti ve Cont ont act : Cont ont ent ent - Leng Lengt h: 0

The IP phone indicates that it honors the request by responding to the NOTIFY with a 200 OK. NOTE:

For brevity, the authorization authorization procedure procedure is not shown in the diagram. The phone phone should should always challenge an incoming NOTIFY for credentials that authorize the notifier to perform remote call control.

[ F13 F13] 200 OK I P Phon Phone e - > Appl i cat cat i on Server erver SI P/ 2. 0 200 200 OK Vi a: SI P/ 2. 0/ UDP a1. a1. f oo. com: 5060 5060;; bran br anch= ch=m9hG 9hG4bK7 4bK74b 4bff 9 Fr om: “ J oe” ; t ag=5f xced76s2 xced76s2 To: To: “J ane” ane” ; t ag= ag=432d 432d33 33 Cal l - I D: 9848 984827 2762 6298 9822 2201 0188 8851 512@ 2@ a1. a1. f oo. com CSeq: 444 NOTI FY Cont ont act act : Cont ont ent ent - Leng Lengt h: 0

The phone then performs the call-hold action.

6.3

Event Package Names The event package name is called “hold”. It is carried in the the Event and Allow-Events header, as defined in RFC 3265.

6.4

Event Package Parameters This event package does not define any event package parameters.

6.5

SUBSCRIBE SUBSCRIBE Bod ies The hold event packages does not support dynamic subscriptions through SUBSCRIBE requests.

6.6 6.6

Subscr ipti on Duration Subscriptions are implied by sessions established through INVITE requests and last throughout the duration of the session. When a UAC sends an INVITE to a UAS, it adds Allow-Ev -Event ents s header to the request, indicating all of the event packages it supports. an Allow This implicitly creates the subscription between the UAC and the UAS. When a UAS responds to the INVITE with an 18x provisional response or 200 OK response, it adds an Allow Allow-Eve Events nts header, indicating all of the event packages it supports. This implicitly creates the subscription between the UAS and the UAC. These subscriptions last until the session has been terminated with a BYE or CANCEL transaction.



05-BD5031-00 PAGE 36 OF 39

6.7

NOTIFY NOTIFY Bo dies A NOTI NOTIFY FY for a hold package MUST NOT contain a body. No body is required as they have trivial state.

6.8 6.8

Subscr iber Generation Generation of SUBSCR SUBSCRIBE IBE Requests Requests Subscribers should not generate SUBSCRIBE requests. Subscriptions are granted to subscribers implicitly, by the establishment of sessions between two user agents.

6.9 6.9

Notifi er Processin g of SUBSCRI SUBSCRIBE BE Requests Requests Notifiers should not process SUBSCRIBE SUBSCRIBE requests. If received, they should be rejected.

6.10 6.10 Subscr iber Process Process ing of NOTIF NOTIFY Y Requests Requests In general, subscriber processing of NOTIFY requests MUST follow all rules with respect to subscriber behavior, as described in RFC 3265. The SIP Specific Event Notification framework expects packages to specify how a subscriber processes NOTIFY requests and, in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. Because these event notifications have the ability to remotely control the user’s handset behavior, the subscriber (for example, the phone) SHOULD perform some level of authorization before processing NOTIFYs. The subscriber MAY perform implicit authorization, by looking at the source IP address of the NOTIFY request event and matching it to any one of the IP addresses of the notifier (in this case, the Application Server) as resolved through DNS. The subscriber MAY perform explicit explicit authentication by challenging the notifier, by using a “401 Unauthorized” response. If the subscriber has also registered a location for this address of record, then the notifier SHOULD use those same credentials to answer the notification challenge. When a subscriber receives a hold event notification for a particular dialog, it must apply the “hold” action to the local session in progress. If the session is in the active state, then it should be held. If it is in any other state, the request should be rejected. Note that the subscriber should always respond to the NOTIFY transaction if it was received and before the action is complete. A 200 OK response to a NOTIFY transaction only indicates that the notification has been received, and not that any action associated with the notification was successfully completed.

6.11 6.11 Handli Handli ng of Forked Requests SUBSCRIBEs and NOTIFYs should not be forked.

6.12 6.12 Rate of Notifi cations The rate of notifications is dictated by the end-user interface on the call control client and can vary from application to application. Endpoints should be prepared to accept NOTIFY NOTIFY requests as frequently as once every two or three seconds.

6.13 6.13 Noti fi er Generation of NOTIF NOTIFY Y Request s Notifications are generated for the hold package whenever a remote call control application requests that an active session be held. Notifiers should not generate a hold event notification for a session that is already in the held state.



05-BD5031-00 PAGE 37 OF 39

7

Index Notifier Processing of SUBSCRIBE Requests, 27 NOTIFY bodies, 27 Rate of Notifications, 28 SUBSCRIBE bodies, 26 Subscriber Generation of SUBSCRIBE Requests, 27 Subscriber Processing of NOTIFY Requests, 27 Subscription duration, 26 Message flow example, 12, 14, 25, 29, 34 Name Event Package Call-Info, 21 Line-Seize, 26 Remote Control Hold, 36 Remote Control Talk, 31 Notifier Generation of NOTIFY Requests Call-Info, 22 Line-Seize, 27 Remote Control Hold, 37 Remote Control Talk, 33 Notifier Processing of SUBSCRIBE Requests Call-Info, 22 Line-Seize, 27 Remote Control Hold, 37 Remote Control Talk, 32 NOTIFY bodies Call-Info, 22 Line-Seize, 27 Remote Control Hold, 37 Remote Control Talk, 32 Outgoing Call, 16 Parameters Event Package Call-Info, 22 Line-Seize, 26 Remote Control Hold, 36 Remote Control Talk, 31 Protocol Requirements Line-Seize Event Package, 24 Rate of Notifications Call-Info, 23 Line-Seize, 28 Remote Control Hold, 37 Remote Control Talk, 32 Remote Control Hold Event Package, 34 Event Package Name, 36 Event Package Parameters, 36 Example message flow, 34 Handling of Forked Requests, 37 Notifier Generation of NOTIFY Requests, 37 Notifier Processing of SUBSCRIBE Requests, 37 NOTIFY bodies, 37 Rate of Notifications, 37

Address Address of Record, Record, 7, 14 Answer Answer-Af -After ter,, 11 11 Example message flow, 12 Overview, 11 Appear Appearanc ance-i e-index ndex,, 11 11 Appear Appearance ance-in -index, dex, Appeara Appearance nce-sta -state, te, Appear Appearanc ance-UR e-URI, I, 7 Call-Info, 7 Event Package, 14 Event Package Name, 21 Event Package Parameters, 22 Example message flow, 14 Handling of Forked Requests, 23 INVITE requests, 8 Notifier Generation of NOTIFY Requests, 22 Notifier Processing of SUBSCRIBE Requests, 22 NOTIFY bodies, 22 Outgoing Call, 16 Rate of Notifications, 23 Responses, 9 Shared Call Appearance, 14 SUBSCRIBE bodies, 22 SUBSCRIBE requests, 11 Subscriber Generation of SUBSCRIBE Requests, 22 Subscriber Processing of NOTIFY Requests, 23 Subscription duration, 22 Event Package Call-Info, 14 Line-Seize, 24 Remote Control Hold, 34 Remote Control Talk, 29 Extensions to Call-Info, 7 Forked Requests Call-Info, 23 Line-Seize, 28 Remote Control Hold, 37 Remote Control Talk, 32 Hold, remote control, 34 Info-parameter Answer-A Answer-Afte fter, r, 11 Extensions to Call-Info, 7 Introduction, 6 INVITE requests, 8, 14 IP Phone Power Up A-1 SCA Client Client Subscr Subscript iption ion,, 14 14 Line-Seize, 11 Event Package, 24 Event Package Name, 26 Event Package Parameters, 26 Example message flow, 25 Handling of Forked Requests, 28 Notifier Generation of NOTIFY Requests, 27



05-BD5031-00 PAGE 38 OF 39

SUBSCRIBE bodies, 36 Subscriber Generation of SUBSCRIBE Requests, 37 Subscriber Processing of NOTIFY Requests, 37 Subscription duration, 36 Remote Control Talk Event Package, 29 Event Package Name, 31 Event Package Parameters, 31 Example message flow, 29 Handling of Forked Requests, 32 Notifier Generation of NOTIFY Requests, 33 Notifier Processing of SUBSCRIBE Requests, 32 NOTIFY bodies, 32 Rate of Notifications, 32 SUBSCRIBE bodies, 31 Subscriber Generation of SUBSCRIBE Requests, 32 Subscriber Processing of NOTIFY Requests, 32 Subscription duration, 31 Responses, 9


Shared Call Appearance, 14 SUBSCRIBE bodies Call-Info, 22 Line-Seize, 26 Remote Control Hold, 36 Remote Control Talk, 31 SUBSCRIBE requests, 11 Subscriber Generation of SUBSCRIBE Requests Call-Info, 22 Line-Seize, 27 Remote Control Hold, 37 Remote Control Talk, 32 Subscriber Processing of NOTIFY Requests Call-Info, 23 Line-Seize, 27 Remote Control Hold, 37 Remote Control Talk, 32 Subscription duration Call-Info, 22 Line-Seize, 26 Remote Control Hold, 36 Remote Control Talk, 31 Talk, remote control, 29


05-BD5031-00 PAGE 39 OF 39

Broadsoft BroadWork SIP

Recommend Documents