Signaling

SIP Implementation & Call Flows For Business Telephony Features

Version: 091504-1

Abstract This document contains a basic description of the Sylantro Application Server’s SIP -based business telephony features delivered on SIP telephony endpoints. The document details the call flows for supporting the various business telephony features and the pointers to relevant SIP RFCs and drafts that SIP user agents must comply with to implement the features. Partners implementing features against the Sylantro Application Server can use the document as a reference.

SIP Business Telephony Features Call Flows

SYLANTRO SYSTEMS Page ii

Table of Contents

1. INTRODUCTION ................................................................................................................. 1

1.1. SIP USER AGENT FRAMEWORK FOR BUSINESS FEATURES ............................................. 1 1.2. THE ROLE OF IETF SIP STANDARDS AND BEST CURRENT PRACTICES ........................... 3

1.2.1. A Note on IETF Internet Drafts ............................................................................... 4

2. CALL FLOWS....................................................................................................................... 5

2.1. APPLICATION SERVER – REGISTRATION, BASIC CALL FLOWS ........................................ 5 2.1.1. SIP Phone Registration............................................................................................ 5 2.1.2. SIP UA to UA Basic Call ......................................................................................... 6 2.1.3. Call Hold.................................................................................................................. 7 2.1.4. Call Transfer............................................................................................................ 8 2.1.5. Call Waiting............................................................................................................. 8 2.1.6. SUBSCRIBE............................................................................................................. 9 2.1.7. Message Waiting Indication .................................................................................... 9

2.2. APPLICATION SERVER – BUSINESS TELEPHONY FEATURES .......................................... 10 2.2.1. Last Call Return..................................................................................................... 10 2.2.2. Directed Call Pick Up/ Group Call Pick Up ......................................................... 11 2.2.3. Call Park................................................................................................................ 13 2.2.4. Call Pick Up (Picking Up a Parked Call) ............................................................. 15 2.2.5. Call Flows for Distinctive Ringing, Visual Alert and Auto Answer....................... 16 2.2.6. Multi Stage Digit Collection (Billing Codes, Authorization Codes)...................... 20 2.2.7. ACD Agent Check-In/Check-Out of an ACD Queue.............................................. 21 2.2.8. ACD Agent Available/Un-available....................................................................... 23 2.2.9. Calling and Called Party Display.......................................................................... 25 2.2.10. SIP Centralized Conferencing ............................................................................... 26 2.2.11. Call Forward Indication........................................................................................ 28


SYLANTRO SYSTEMS Page 1

1. Introduction

The objective of this document is to describe SIP call flows supported by the Sylantro Application Server to enable business telephony features for SIP endpoints, presenting the information in a format that can be easily distributed to Sylantro’s partners and customers as a basis for interoperability. The document does not contain any design, detailed architecture, or configuration information of the Sylantro Application Server. The scope of this document is currently directed towards interoperability between the Sylantro Applications Server and SIP user agents (e.g., SIP telephony devices). It is Sylantro’s intention that this document will form the basis of a group of SIP call flow profiles encompassing all features for SIP user agents.

In addition to the call flow profiles in this document, Sylantro has also submitted to the IETF an internet draft describing and detailing the call flows in support of Bridge Line Appearances (aka Shared Line Appearances) feature. The current version of the BLA draft is draft-anil-sipping-bla-01.txt. Sylantro is also planning to submit a separate internet draft for ACD application call flows in the near future. The BLA and ACD call flow drafts are intended to complement the existing internet draft on SIP service examples (draft-ietf-sipping-service-examples-06).

1.1. SIP User Agent Framework For Business Features

The feature and functionality requirements for SIP user agents supporting business telephony differ vastly from basic SIP user agents in terms of the features that they support and end user experience. Specifically, many of the business-grade devices provide much richer display that are used to provide enhanced services, set of soft and hard keys that enable much easier feature usage/navigation and fairly rich set of end user features. The business features and services may be broadly classified under the following categories:

• Line Capabilities • Monitoring Capabilities • Applications

Line capabilities are those that enable basic telephony services. These are used for call processing. This set enables users to place calls, receive calls and so on. From a SIP signaling perspective, a user agent MUST be able to REGISTER and refresh registrations at periodic intervals; and be able to generate INVITES and handle incoming INVITES. User status monitoring capabilities serve a dual purpose. They enable line features (so a user can choose to use his line appearance to place outbound calls or answer inbound



calls), and as status indicators, so if another user in the system is using the same, an indication to that effect is provided. From a SIP signaling perspective, this capability calls for the UA to REGISTER at startup and refresh registrations as well. In addition this capability needs for the UA to SUBSCRIBE for the dialog state upon start up and periodically refresh the subscriptions as desired. This would enable it to monitor call states on other phones that have this URL administered on their phones. Applications on the SIP telephony devices include (but not limited to) those that enable the various features on a typical business telephone. Each of these has a defined set of functionality when invoked based on the kind of feature they enable on the device. From a SIP signaling perspective, the kind of messages that get exchanged depends upon the feature. For example, speed-dial feature on invoke, would send out an INVITE to its configured proxy providing the number stored against this button in the Request URI. The Hot Line feature on invoke would send out an INVITE to a pre-configured URL. The DND feature, when activated, would reject any incoming call meant for the UA with a 486 Busy response code. There are other applications that may indicate the “status” of a particular application the user has enabled on the phone. For example, an application that is configured to monitor ACD agent availability or status might indicate to the end user the ACD state information, i.e.; whether the user has checked into the ACD queue or not. From a SIP messaging perspective, these keys will have to be able to handle sending/receiving SUBSCRIBE and NOTIFY. There may be other features which from a SIP signaling perspective could translate to sending a 302 response (like forward to VM) or send a REFER on an established call leg (like call park). Regardless of the type of application, most of these are associated with a visual indicator that indicates when application is in use or active. Most also provide a visual means to indicate to the end user about media states of (for example the visual indication MAY be a flashing LED to indicate media state on HOLD, steady LED to indicate were media state is two way and so on if the UA is a hard phone that has LEDS). Most business telephony devices provide an end user capability to update or add new applications at any time. Some of these applications may be implemented locally on the phone, while for a few other features; the phone has the capability to indicate to the network of this feature and request it’ s services for the same. So also, these phones have the capability provide different alerting capabilities like playing different wav files or providing a dialog box based on information provided to them by a network element. They also allow the network element to indicate to the end UA, as to whether the “alert” mechanism to use to notify the end user of an incoming call should be via audio or simple visual notification or a warning tone. Almost all business telephony devices have a display that is used for enabling a variety of features. One such example is indicating incoming calling name and numbers. The display is also used to provide what are known as “soft keys”. These are feature buttons but appear on the display as against being associated to a fixed button. Again, similar to those of the feature keys, each of these have varying capabilities based on the feature they



enable. So also, some of these soft key features may be locally implemented on the phone, whereas a few of them indicate the feature invoke via signaling.

1.2. The Role of IETF SIP standards and Best Current Practices

Sylantro strongly recommends and committed to the implementation of features based on IETF SIP standards and best current practices. The table below highlights the list of business telephony features that are described in this document and their implementation based on IETF RFCs and Internet Drafts:

SIP Business Telephony Feature in Sylantro Server R3.1

SIP UA RFC and Internet Draft Compliance

1. Registration (w/ MD5 Digest Auth) RFC 3261 2. Hold RFC 3264 3. Message Waiting Indication (MWI) draft-ietf-sipping-mwi-04

RFC 3265 4. Transfer (Blind, Supervised, Consult.) RFC 3515

draft-ietf-sipping-service-examples-06 5. Calling and Called Party Display RFC 3325

draft-venkatar-sipping-called-name-00 6. Call Park draft-ietf-sipping-service-examples-06

RFC 3515 Keyword “ callpark” per RFC 3087

7. Call Pickup draft-ietf-sipping-dialog-package-04 draft-ietf-sip-replaces-04 Keyword “ pickup” per RFC 3087

8. Directed Call Pickup RFC 3265 draft-ietf-sipping-service-examples-06 draft-ietf-sipping-dialog-package-04 draft-ietf-sip-replaces-04

9. Group Call Pickup RFC 3265 draft-ietf-sipping-service-examples-06 draft-ietf-sipping-dialog-package-04 draft-ietf-sip-replaces-04 Keyword “ groupcallpickup” per RFC 3087

10. Intercom RFC 3261 Alert Info header 11. Multi-Stage Digit Collection RFC 3261 “ 484 Address Incomplete” 12. Distinctive Ringing RFC 3261 Alert Info header 13. Call Forward Indication RFC 3265

“ missed-call-summary” message body of type “ message/sipfrag”

14. Last Call Return RFC 3261 Keyword “ lcr” per RFC 3087

15. ACD Agent Check-In/Check-Out RFC 3265 16. ACD Agent Available/Unavailable RFC 3265

draft-ietf-simple-presence-10 draft-ietf-impp-cpim-pidf-08

17. Bridge Line Appearance (BLA) draft-anil-sipping-bla-01 RFC 3265 draft-ietf-sipping-dialog-package-04 RFC 3680

18. Ad-hoc Centralized Conferencing draft-burger-sipping-netann-08



draft-ietf-sipping-cc-conferencing-01 19. Sylantro App feature access via phone top

browser HTTP A Markup language (e.g., WML, XHTML, CCXML,…)

In addition, the SIP telephony devices should adhere to the requirements in the following internet draft draft-sinnreich-sipdev-req-03.txt. (Note: Sylantro initially had submitted an IETF requirements draft for SIP business telephony devices (draft-sharath-sipb-requirements-00.txt). Many of the requirements in Sylantro draft are also addressed in the draft-sinnreich-sipdev-req-03.txt. Sylantro is in agreement with the IETF community to pursue a single requirements document for SIP devices and will support the BCP effort initiated in the sip devices draft. At the same time, Sylantro has submitted the call flow drafts for business features not yet addressed in any drafts or RFCs)

1.2.1. A Note on IETF Internet Drafts IETF Internet Drafts are valid for six months after they are submitted to the IETF. Many of them are refreshed sometime before or after they are expired and some eventually are published as standards track, informational, and BCP RFCs. The internet drafts that are referenced in the above table are the versions that have been used in the implementation of business features in Release 3.1 of Sylantro Server software.



2. Call Flows

The Sylantro Application Switch can interact with SIP endpoints to enable SIP UA’s to perform basic call set up and teardown and offer Sylantro Application Server’s business telephony features like call park, call pick up last call return, bridged line appearance and so on. The SIP interaction includes call control and media negotiation as defined in RFC 3261.

2.1. Application Server – Registration, Basic Call Flows

In this configuration, the Sylantro Server performs all routing functionality, including handling of REGISTER requests from various SIP endpoints; maintaining a registration database; and offering the call to the right UA based on SIP URL dialed by the user and the SIP Contact registered for this SIP URL.

2.1.1. SIP Phone Registration In this scenario, the Application Server takes the role of SIP Registrar. The REGISTER request received is challenged and upon successful responses an entry is placed in to the routing database for the address of record the UA registered for. The Application server currently supports MD5 Digest Authentication.



2.1.2. SIP UA to UA Basic Call In this scenario, the Application Server takes the role of back to back user agent or a proxy (based on the feature set enabled on the called SIP URL) challenges the INVITE and upon successfully being able to authenticate this request it shall forward the same to the appropriate end user agent. The call flows here are same as those mentioned in RFC 3261 and are mentioned here for completeness.



2.1.3. Call Hold The Sylantro Application Server supports Call Hold in the following two different ways. The first approach is based on RFC 3264 where by a UA that intends to place the caller on Hold sends out an INVITE with the SDP containing the IP address 0.0.0.0 or setting the media attribute to "sendonly". The Sylantro Application server interprets this to be a request for Music on Hold and provides SDP of a music source to the far end. The second call flow is based on call flows provided in the sipping-examples draft. Here basically the UA that wishes to place a call on hold temporarily acts as a B2B user agent; it sends out an INVITE with no SDP to the announcement resource, gets it’s SDP and provides this SDP as a REINVITE to the caller.



The call flow below is the message exchange based on the sipping-examples draft.

2.1.4. Call Transfer The Sylantro Application server support transfers based on the REFER method outlined in RFC 3515 and sections 2.4 and 2.5 of the sipping service examples draft as outlined in draft-ietf-sipping-service-examples-06.txt.

2.1.5. Call Waiting The Sylantro Application server does not do anything specific to control call waiting or temporarily disable call waiting on a per end point basis.



2.1.6. SUBSCRIBE

The SIP UA should be able to support SUBSCRIBE/NOTIFY for various Event packages as defined in RFC 3265. Sample call flows for the same are as below.

2.1.7. Message Waiting Indication The Sylantro Application Server supports interfaces to traditional VM and IP UM systems. In cases where the server interfaces to traditional VM systems, the Sylantro Application Server generates NOTIFY messages based on the Message Waiting Indicator draft outlined in draft-ietf-sipping-mwi-04.txt. The Sylantro Application server prefers SIP UA’s to SUBSCRIBE for MWI indicators on startup and refresh subscriptions as appropriate. This is not a necessity. By default the Sylantro Platform assumes implicit subscriptions for MWI when a SIP UA REGISTERS with it. The call flows provided below are same as those in the draft, but are mentioned here for completeness.



2.2. Application Server – Business Telephony Features

The section that follows has call flows that are used to implement some of the business telephony features, the list of drafts and/or RFCs that are required of SIP UA’s if they need to participate in a Sylantro Application Server hosted environment. Note that these features will be available on the Sylantro Application Server in Release 3.1.

2.2.1. Last Call Return SIP UA’s that wish to use the feature with the Sylantro Application environment must be able to send out an INVITE to the Request URI "sip: [email protected]". The Request URI user "lcr" is a reserved service key word per RFC 3087. The Sylantro Application Server will translate this request and route this call to the appropriate party (the last incoming caller for the user identified in the From User or the P-Asserted-Identity header in the INVITE).



Call flows for the same are as below:

Thus the UA need to support the following drafts/IDs to enable this feature:

• RFC 3261 • Understand "lcr" as a key word.

2.2.2. Directed Call Pick Up/ Group Call Pick Up UA’s that wish to support this feature with the Sylantro Application Server must be able to send out SUBSCRIBES and receive NOTIFY’s for the "dialog state" package outlined in "draft-ietf-sipping-dialog-package-04.txt". The call flows for these are based on those outlined in the sipping-examples draft at the IETF. When the user initiates a directed call pickup, the SIP UA will send out a



SUBSCRIBE with Event set to "dialog" towards B with the Expires header set to 0. This request is authenticated by the outbound proxy and on successful authorization shall be forwarded to user B. The SIP UA on receipt of the NOTIFY, will inspect the list of dialogs that are "early". If more than one dialog is in "early" state, the UA might provide a UI of some sort to request the end user which of these calls he/she wants to pick. On appropriate selection, the UA shall send out an INVITE with the Replaces header containing the dialog identifiers that was selected by the end user or the UA automatically. The UA should also indicate in the Replaces header that it intends to "pick" the call that is not established (to account for a race condition where in before this INVITE with Replaces header is received by the calling UA, the called UA actually answers the call). It does so by placing the "early-only" parameter in the Replaces header dialog identifiers. The calling UA on receipt of this request shall accept this request if the dialog this is replacing is "still in early-only" state and CANCEL the original request thus completing the call pick up. The call flows for group call pick up remain the same except that the UA initiating a group call pick up shall send out the SUBSCRIBE to the SIP URL sip: [email protected] instead of the specific SIP URL entered by the end user. Thus in summary any UA that wishes to use the Sylantro Application Server for implementing this feature must support the following

• Support for SUBSCRIBE/NOTIFY (RFC 3265) • Dialog State ID as outlined in draft-ietf-sipping-dialog-package-04.txt • Support for the extension to Replaces header as outlined in the above section. • Understand "groupcallpickup" to be a keyword per RFC 3087.



2.2.3. Call Park The call flows for Call Park is based on the sipping-service examples draft as outlined in draft-ietf-sipping-service-examples-06.txt.



A UA that wants to park the call, shall prompt the user the orbit against which the user wants to park this call, and on obtaining this information shall issue a REFER with the Refer-To URL as sip: [email protected];orbit=<userenterednumber>. While the example above uses a number in the "userenterednumber" value field, this may be any valid string such as "call for john".



In summary, any SIP UA interested in participating in a Call Park service with the Sylantro platform must support the following:

• Support for initiating a REFER (RFC 3515). • Understand "callpark" as a reserved Request URI keyword per RFC 3087. • Provide an interface for end user to place the call park digits. • Initiate a REFER providing this orbit information to the called target. • Support for reconnecting back to the Referred UA in case the park request fails.

2.2.4. Call Pick Up (Picking Up a Parked Call) SIP UA’s that intend to use the Sylantro Application Server for enabling this feature must implement the call flow below (flow assume that B is parked at orbit 5000). Please note that the call flow does not show INVITE authentication as a part of these call flows for simplicity. It should be noted that the Proxy MAY challenge INVITES before the same is accepted and processed upon.

In summary a UA that wishes to make use of the Sylantro Application Server for Call Pick up must support the following:

• Support and understand the dialog state draft as outlined in draft-ietf-sipping-dialog-package-04.txt.

• Understand the Request URI user "pickup" to be key word per RFC 3087.



• Support the Replaces header as outlined in draft-ietf-sip-replaces-04.txt.

2.2.5. Call Flows for Distinctive Ringing, Visual Alert and Auto Answer Support for all the above features relies on the ability of the SIP UA to understand and interpret and place certain key words in the "Alert-Info" header of a SIP INVITE request. For enabling distinctive ringing, the proxy forwarding the INVITE request will place a HTTP URL in the Alert-Info header that provides the type of tone that need to be rendered to the end user. The document strongly recommends that UA’s be able to fetch these files and render the same to the end user. For UA’s that don’t support a HTTP client, the Proxy will also add a "hint" as an Alert-Info param that may be inspected by the UA to decide what tone to render to the end user. The details as to what tone to render to the end user is left to the UA. The document recommends that such UA’s have the capability to provide at-least 4 different ring tones and map the various key words to one of the tones supported by the UA. Provided below are three call-flows, which provide examples of a few call scenarios and usage of the Alert-Info header.



To facilitate features that require auto-answer, the draft adds an additional parameter called "delay" in the Alert-Info header. The value for the same is in "seconds" and is used to provide details to the UA as to how long the file fetched from the HTTP URL needs to be played before answering the call automatically. Absence of this parameter should be considered as "ring forever". The example call flow below indicates how the same is used.



The following is a complete list of key words that may be present as the "info" param in the Alert-Info header: "alert-group", "alert-external", "alert-internal", "alert-visual", "alert-emergency", "alert-autoanswer", "alert-priority", "alert-acd", "alert-community-1", "alert-community-2", "alert-community-3" and "alert-community-4".

2.2.6. Multi Stage Digit Collection (Billing Codes, Authorization Codes) Features like mandatory and optional billing codes, authorization codes require that the application server notify the SIP UA to collect more digits before completing the call.



The Sylantro Application server achieves these features by using a response code of 484 Address Incomplete in conjunction with the Warning header that provides enough information that can be used by a UA to render to the end user to prompt for more digits. The same is a part of the base SIP specification specified in RFC 3261. Provided below is an example call flow that enables mandatory billing codes on a SIP UA.

2.2.7. ACD Agent Check-In/Check-Out of an ACD Queue Any SIP UA that wishes to be a part of an ACD agent group hosted by the Sylantro Application Server must be able to support the semantics for "Checking In" and "Checking Out" of the ACD agent group. The Sylantro Application Server relies on the ability of the UA to be able to perform third party SUBSCRIBE’ s to login and logout of the ACD group. It should be noted that these Subscriptions should not be pre-programmed and the UA should not automatically initiate Subscriptions to these addresses when it is restarted or rebooted.



From a user interface perspective, whenever a user indicates to the UA (via a key press or a soft key or any UI of choice provided by the phone) that he/she intends to "login" to an ACD group, the UI shall prompt the user to enter the ACD Group ID to login to, following which it MUST prompt the end user to enter a password. The end user may choose not to enter any when prompted for the password.

Once entered, the phone sends out a SUBSCRIBE with the "From" URL containing the user’s identification (the SIP AOR with which the phone successfully registered with the Registrar, in the example below, <sip:[email protected]> ). The "To" URL should contain the ACD group Logi-n ID the user entered (in the example above, <sip:[email protected]> ). Note that the domain is automatically appended by the UA and end user need not enter this information.



The Sylantro Application server may challenge this request with a 401-response. In such event, the phone sends out a new SUBSCRIBE with the Authorization header containing the credentials computed using the "ACD Login Group ID" and the "ACD password" entered by the user. The Sylantro Application Server MAY choose an Expires with a shorter timeout if deemed necessary. It is the responsibility of the UA to refresh subscriptions when these expire. This is in accordance with RFC 3265. The SIP UA MUST provide indication that the user agent has logged into to an ACD group ONLY AFTER it has received a successful 2xx response for the SUBSCRIBE it sent out towards the Sylantro Application Server. So also, whenever a refresh subscription or a new subscription (attempt to login to an ACD group) fails the UA must provide some indication to the end user to that effect. It should be noted that a successful subscription to the ACD agent address implicitly installs a “hard reverse subscription” at the UA. The rational for the same are detailed in section 2.2.8 below. Since this reverse subscriptions is “hard”, the same MUST NOT be terminated in cases where an attempt to NOTIFY state changes times out (which is again in conformance with RFC 3265). Once successfully "logged in" to an ACD group, the UA MUST provide a mechanism for the end user to "log out" of an ACD group. Whenever the end user invokes the same, the SIP UA MUST send out a SUBSCRIBE with Expires set to 0 and the Contact containing its SIP URL so that the ACD application can log the agent out of the ACD group. The UA must not attempt to "automatically" refresh the ACD subscriptions once the end user has requested the UA the "log out" operation. It must also provide an indication to the end user indicating that he/she has logged out of the ACD group. Successfully logging out an ACD group also implicitly terminates the reverse subscription that got installed at the time of subscription. The user agent MUST be capable of supporting a NOTIFY with Subscription-State “ terminated” . On receipt of such a NOTIFY, the User-Agent MUST indicate to the end user that he/she has been logged out of the ACD group. On receipt of such a NOTIFY, it must abandon any efforts to automatically refresh SUBSCRIBE until it receives any input from the end user.

2.2.8. ACD Agent Available/Un-available Another aspect of the Sylantro Application Servers ACD functionality is the ability of the ACD agent to make himself/herself "available" or "unavailable" from an ACD queue. This allows the ACD agent/Sylantro Platform to temporarily stop offering calls to the agent even though he/she is logged in to an ACD group. It is for this reason that the “ implicit hard subscription” as outlined in the previous section is required. The UA shall use the same to send out NOTIFY’ s when such an activity is initiated by the end user.



The Sylantro application server also provides interfaces, which allow either the end user or the administrator to make an agent “ available” or “ unavailable” via an external interface. The Sylantro Application Server makes use of the SUBSCRIBE dialog established in 2.2.7 above as a means to signal between the UA and the Application about the status of the agent. Upon successfully logging into the ACD group, the SIP UA and the Sylantro Application Server send out NOTIFY’ s to each other, indicating the presence status of each other based on the SIP Presence draft outlined in draft-ietf-simple-presence-10.txt. As with ACD login functionality, the UA MUST provide any end user indication about successfully making the end user available/unavailable only after it has received a successful 200 OK response for the NOTIFY.



Every time the end user or the Sylantro Application Server change the availability status, the SIP UA or the Sylantro Application Server send out a NOTIFY providing the "current status" in the NOTIFY message body in XML as defined by draft-ietf-impp-cpim-pidf-08.txt. The status “ open” in the XML payload shall correspond to end user state being “ Available” and “ closed” in the XML payload shall correspond to end user state being “ Unavailable” .

2.2.9. Calling and Called Party Display



The Sylantro Application Server uses the P-Asserted-Identity header defined in RFC 3325 to transmit calling and called party identification information to SIP UA’s. Any SIP UA that is interested in using the Sylantro Application Server must use information in this header to render information to the end user. The SIP UA must inspect this header in every SIP request or response and use information in this header to render to the end user. The initial value provided in the P-Asserted-Identity header holds in cases where new SIP requests or responses (like REINVITE, or UPDATE) don’t have this information. Apart from this, there is no other requirement on the SIP UA for enabling this feature.

2.2.10. SIP Centralized Conferencing



SIP UA’s that wish to make use of the Sylantro Application Server as a mediation platform between a conference server and itself must implement the call flows in the SIP Conferencing draft outlined in burger-sipping-netann-07.txt and those outlined in draft-ietf-sipping-cc-conferencing-01.txt.



On a high level, the SIP UA that wants to make use of a centralized conference server first sends out an INVITE with the request URI user part containing the key word "conf" to indicate that the request is for a conference. The Sylantro Application Server serves as the "focus UA" for this call flow. The Sylantro Application Server reserves the key word "conf" to be the conference-factory URI as defined by the conferencing draft. The server shall be responsible for translating the request to reserve appropriate conferencing resources and on successfully being able to allocate resources respond back with a 200 OK providing the appropriate Contact. Once the initial request to allocate resources for a conference is accepted, the SIP UA sends out a REFER request to other UA’s it intends to bring into the conference with the Refer-To header containing the unique identifier that identifies the conference and thus achieved. The Sylantro Application Server, acting as a B2BUA terminates the REFER requests from the SIP UA and in part initiates Re-INVITEs towards other parties to connect to the Conference Server. Call flows above illustrate the peer-to-peer message flows between users. From the perspective of the SIP UA initiating the conference, the call flows are identical.

2.2.11. Call Forward Indication The Sylantro Application server supports providing end users indication to the end user whenever it is diverting the call meant for the end user to a different destination address. The same is achieved by using SUBSCRIBE and NOTIFY. UA’s that need to make use of this feature must send out a SUBSCRIBE with the Event containing the key word "missed-call-summary". The UA must be prepared to Accept NOTIFY message bodies of type "message/sipfrag". Once subscribed successfully, the Sylantro Application Server will send out NOTIFY’s with the payload "message/sipfrag" every time it diverts a call for the end user to a different destination. The payload data would contain all SIP headers, which can be used by the UA to determine the calling party whose call was diverted (the From, To, Call-Id, the P-Asserted-Identity, Remote-Party-Id).

Signaling

Documents

Transcript of Signaling