Microsoft s Proposal to the SIP Forum. For SIP Trunking Interoperability

Transcription

2 1. Introduction Requirement levels Goals Non-Goals Scenarios Architecture Protocol Flow and Procedures Service Provider Proxy Discovery Static Provisioning Enterprise Proxy Discovery Connection Establishment and Management Variant 1 IP VPN Variant 2 TLS and SRTP Requirements for interfacing with the Enterprise Proxy General requirements SIP over TCP DNS support IPv4 support Media processing Voice calls Early media Address formatting Service Provider Proxy failover and error scenarios Management and default mappings Globalization / localization Function specific requirements Outbound call with Early Media Call placed on Hold by Enterprise network and then reconnected Active call is disconnected Inbound call SIP support summary Functions Methods Headers Responses...33 Copyright 2008 Microsoft Corporation. All rights reserved. Page 2

3 1. Introduction The purpose of a SIP Trunk as defined in this document is to enable an enterprise to connect their onpremise voice network infrastructure to a service provider offering PSTN origination, termination, and emergency services by making use of the SIP protocol. The benefits to the enterprise customer is reduced costs in deploying voice by using an industry standard voice protocol (SIP) for PSTN access rather than deploying IP PSTN gateways within the enterprise network, where these gateways terminate legacy PSTN protocols such as ISDN and T1. This specification documents the intended protocol interface between the call routing infrastructure (Enterprise Proxy) and the service provider s network (Service Provider Proxy). It is meant as a complete specification suitable for implementation, testing, and certification of interoperability between the customer premise equipment and the service provider. 1.1 Requirement levels This document uses the same key words as IETF drafts and RFCs when defining levels of requirements. In particular, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for compliant SIP Peer implementations. In addition to the above this document makes use of NR ( not required ) where appropriate. 1.2 Goals It is anticipated that this SIP Trunking specification will evolve over time to introduce new features as well as to improve upon the specification based upon operational experience. It is built upon established, industry proven standards from the IETF. It is a goal to adopt existing SIP standards wherever applicable to foster the greatest possible interoperability with service provider equipment. At the same time, it is expected that the state of the art for SIP Trunking will evolve over time to tackle additional problems such as mobility where additional capabilities may be required. 1.3 Non Goals It is not a goal for SIP Trunking at this point in time to support additional services such as presence, instant messaging, or web conferencing. The focus of the SIP Trunking service is voice communications. Copyright 2008 Microsoft Corporation. All rights reserved. Page 3

4 1.4 Scenarios The set of scenarios for the SIP Trunking interface is as follows: Allow an enterprise user (inside or outside the corporate firewall) to make a local or longdistance call specified by an E.164 compliant number which is terminated on the PSTN as a service of the corresponding service provider. (This would include Calling Party Number presentation.) Allow any PSTN subscriber to contact an enterprise user (inside or outside the corporate firewall) by dialing a Direct Inward Dialing (DID) number associated with that enterprise user. 2. Architecture The architecture is as follows: Internal Firewall External Firewall Figure 1 Enterprise Proxy Behind the DMZ Firewall The diagram above shows a possible architecture for the first phase of implementation and deployment. Note the use of an IP VPN for connectivity between the Enterprise and the Service Provider. It is Copyright 2008 Microsoft Corporation. All rights reserved. Page 4

5 expected that the demarcation point in most service providers networks will be a session border controller (SBC), though this is not required; the only requirement is that the equipment terminating the SIP signaling from the enterprise proxy conforms to this interoperability specification. Likewise, the choice of an IP PSTN gateway or softswitch implementation in the service provider network is entirely a decision made by the service provider. The Unified Communications (UC) clients (Enterprise Users) present in this diagram represent the range of softphone and hardphone devices compatible with Office Communications Server. It is the role of the Enterprise Proxy shown in this diagram to perform any signaling or media translation necessary to conform to the interface defined in this specification. The term Enterprise Proxy is used to describe all roles provided by the Office Communications Server elements and do not indicate 3 rd party equipment. In Figure 1, the Enterprise Proxy is shown behind the internal firewall of the DMZ. This requires that a hole be punched in the external firewall for the VPN connection. It is assumed that the VPN router in the DMZ is hardened and can be configured to accept only VPN traffic from a configured peer. Also, the external firewall of the DMZ is configured to only allow traffic from the VPN peer to terminate on the VPN router. The external firewall does not allow any external traffic to directly reach the Enterprise Proxy. The Enterprise Proxy must be dual homed in this configuration. One Ethernet interface is used to connect to the LAN on which the external firewall is connected. The second Ethernet interface is used to connect to the LAN on which the internal firewall is connected. Behind the Enterprise Proxy, signaling and media traffic traverse the internal firewall onto the enterprise network. 3. Protocol Flow and Procedures 3.1 Service Provider Proxy Discovery Static Provisioning The first procedure invoked by the Enterprise Proxy is discovery of the appropriate Service Provider Proxy for establishment of the SIP Trunk. For Phase 1, only static provisioning is supported whereby the enterprise administrator learns through out of band means either a list of 1 fully qualified domain name (FQDN) or 1 IP address which represent the Service Provider Proxy that should be tried (in order) to establish a connection to the service provider network. If an IP addresses is supplied, it should be static, publically addressable, IPv4 address. If an FQDN is supplied, it must be globally resolvable by DNS to a set of static, publically addressable, IPv4 addresses. A simple DNS A record resolution will be used in this case to resolve the FQDN to an IP address. (Only the first IP address will be used.) Note that for recovery from failure at the Service Provider side, the IP address should be a virtual IP address that can be taken over by backup machine(s) if a primary machine goes down. 3.2 Enterprise Proxy Discovery The Service Provider Proxy will follow a similar set of procedures as in section 3.1 for situations where it needs to connect to the Enterprise Proxy and there are no pre existing connections that may be re used. Copyright 2008 Microsoft Corporation. All rights reserved. Page 5

6 3.3 Connection Establishment and Management Since TLS and SRTP (the preferred mechanisms) are not generally supported in Service Provider networks, an alternative is offered Variant 1 IP VPN In early deployments, it is assumed that a statically provisioned IP VPN or similar private network will be established between the Enterprise Proxy in the Enterprise and the Service Provider network. The purpose of this private network is to provide IP connectivity, security, and (optionally) quality of service guarantees. In such an environment, it is not required to additionally secure the SIP signaling traffic (with TLS) or the media traffic (with SRTP). Connections between the Enterprise and the Service Provider then consist of plain TCP connections for SIP and plain RTP (over UDP) for media potentially tunneled through an IP VPN. The following defines the expected behavior for the enterprise to establish a TCP connection to the service provider or vice versa assuming that the private network (IP VPN) is already in place: The Enterprise Proxy will establish and maintain up to 4 concurrent connections to the Service Provider Proxy There may be multiple Enterprise Proxies (for redundancy and scale) establishing connections The Service Provider Proxy is free to establish additional connections but connection re use is encouraged to conserve resources on each peer. A SIP response MUST go over the same connection that the SIP request was sent over; other SIP transactions may use any available connection. Connections will be established on demand (there are no pinned up connections) and will be recycled at least once every 24 hours. If the maximum concurrent connections (4) are reached, the Enterprise Proxy will not establish a new connection but will instead re use an existing connection. If not statically provisioned, a DNS resolution will be performed for each new connection unless the TTL allows caching of previous results. Inbound connections from the service provider must come via the private network (network isolation will be ensured via appropriate firewall ACLs and/or NIC/VLAN isolation). It is assumed that outbound connections to the service provider will be similarly restricted, possibly by deployment of a session border controller Variant 2 TLS and SRTP In later, or more advanced, deployments, TLS and SRTP connections will be established. This will allow roaming users wishing to make a phone call to securely connect to the enterprise network from the public IP network, but have their media routed directly to the Service Provider Proxy. Copyright 2008 Microsoft Corporation. All rights reserved. Page 6

7 4. Requirements for interfacing with the Enterprise Proxy This section details the additional requirements over those provided in Section 2 that a Service Provider Proxy needs to implement in order to interface with the Enterprise Proxy. 4.1 General requirements This section details the general, overall requirements that need to be implemented in a Service Provider Proxy SIP over TCP SIP, as defined in RFC 3261 is the core control interface between Enterprise Proxy and the Service Provider Proxy. According to RFC 3261 a SIP element MUST support UDP and TCP. However the support of TCP has been made mandatory to accommodate messages larger than 1300 bytes. Since more sophisticated SIP deployments nearly always breach this limit, it is proposed that the Enterprise Proxy and Service Provider Proxy: MUST support TCP MAY support UDP MAY support TLS Future versions of this document will be likely to make the support of TLS mandatory in order to provide security for SIP messages. Vendors are strongly advised to consider the requirements for TLS support in future versions of their products DNS support The Service Provider Proxy MUST be able to translate host names to IP addresses using DNS (Domain Name Service) servers IPv4 support The Enterprise Proxy MUST support IPv4 and MAY support IPv6. The Service Provider Proxy MUST support IPv Media processing The Service Provider Proxy needs to follow the media processing requirements defined in the following sections General The Service Provider Proxy: Copyright 2008 Microsoft Corporation. All rights reserved. Page 7

8 MUST provide media session parameter negotiation (endpoint, CODEC and, if applicable, encryption parameters) through SDP, as defined in the SIP and related RFCs and used in SIP MUST provide media/audio transport using RTP/RTCP over UDP Echo cancellation Echo cancellation MUST be supported Audio codecs The Service Provider Proxy and Enterprise Proxy MUST support the following codecs: G.711 a law G.711 µ law Both the Service Provider Proxy and the Enterprise Proxy MAY support additional codecs Voice calls PSTN endpoints may initiate or receive voice calls to/from the Enterprise network; such voice calls will interact with the Enterprise network via the Service Provider Proxy. The Service Provider Proxy must support transport of voice data encapsulated in RTP over UDP Offer answer model for voice calls This section covers the offer/answer model for voice calls Inbound calls initial session establishment For inbound calls from the Service Provider Proxy to the Enterprise Proxy, the following offer/answer interactions are supported for initial session establishment: The Service Provider Proxy sends an offer in the INVITE, and receives an answer in a 200 OK message from the Enterprise Proxy. The Service Provider Proxy sends an offer in the INVITE, and receives an answer in a reliable provisional message from the Enterprise Proxy; see the section on early media below. No other offer/answer interactions for inbound calls are supported. A new inbound voice call must have a single m=audio line in the SDP in the offer in the Invite. Further, an inbound voice call must not be in a state where both the send and receive directions are inactive. Thus, it is illegal to have an a=inactive attribute for the audio media session in the offer. It is illegal to have the connection address in the SDP set to in the offer; this was the way a call was put on hold for RFC 2543 clients. It is illegal to have the port number set to zero in the media line in the initial offer to signal removal of the media stream. Copyright 2008 Microsoft Corporation. All rights reserved. Page 8

9 The Service Provider Proxy MUST support the following codecs: G.711 a law G.711 µ law Named telephone event The SDP for the offer in the Invite from the Service Provider Proxy includes gateway supported encodings; G.711 a law, G.711 µ law, and named telephone event must be in the offered encodings. Thus, there must be at least 3 payload types corresponding to the audio formats above in the m=audio line in the incoming offer. When selecting the codec to be used, the Enterprise Proxy will always send an SDP answer with G.711 u law or G.711 a law as the preferred audio encoding. It will also always include a payload type for DTMF digit exchange. A Service Provider Proxy may support redundancy as defined in RFC It may include a payload type for redundancy in the media line in the SDP offer sent to the Enterprise Proxy. The mapping attribute will map this to the RED encoding name and the clock frequency (8 KHz). The Enterprise Proxy will respond with an SDP answer that includes the payload type for redundancy as defined above Outbound calls initial session establishment For outbound calls from the Enterprise Proxy to the Service Provider Proxy, the following offer/answer interactions are supported for initial session establishment: The Enterprise Proxy sends an offer in the INVITE, and receives an answer in a 200 OK message from the Service Provider Proxy. The Enterprise Proxy sends an offer in the INVITE, and receives an answer in a provisional response such as a 183 response, or in a reliable provisional response such as 183 (rel100)/prac for an early media interaction; see the section on early media below. No other offer/answer interactions for outbound calls are supported. A new outbound voice call will have a single m=audio line in the SDP in the offer. Further, an outbound voice will never be initiated where both send an receive directions are inactive. The Enterprise Proxy will never send an a=inactive attribute for the audio media session in the outgoing offer. Further, the Enterprise Proxy will never set the connection address in the SDP to in the outgoing offer. It will never set the port number to zero in the media line in the outgoing offer to signal removal of the media stream. The SDP for the offer in the Invite from the Enterprise Proxy to the Service Provider Proxy will have at least 3 payload types corresponding to the following audio formats in the m=audio line: G.711 a law Copyright 2008 Microsoft Corporation. All rights reserved. Page 9

10 G.711 µ law Telephone event/8000 for DTMF When selecting the codec to be used, the Enterprise Proxy will always send an SDP answer with G.711 u law or G.711 a law as the preferred audio encoding. It will also always include a payload type for DTMF digit exchange. The Enterprise Proxy supports redundancy as defined in RFC It will include a payload type for redundancy in the media line in the SDP offer sent to the Service Provider Proxy. The mapping attribute will map this to the RED encoding name and to the clock frequency (8 KHz). A Service Provider Proxy may respond with an SDP answer that includes the payload type for redundancy as defined above if it supports redundancy Supported codecs, packet size and example SDP The following table summarizes the audio codecs supported on this interface: Codec Sampling Rate Packet Time (configurable) G.711 (u law) 8 KHz 20 ms G.711 (a law) 8 KHz 20 ms Named telephone event 8 KHz 20 ms Note that the length of time in milliseconds represented by the media in a packet must be configurable and applies to all supported codecs; this is signaled via the SDP attribute of ptime. The configured value must be the value that is used symmetrically across the Service Provider Proxy to Enterprise Proxy interface. The ptime value must have a configurable value that can be set to 20 ms, 30 ms, 40 ms, 50 ms, or 60 ms. The default value must be 20 ms. The following is an example session description (SDP) representing a typical offer present in the Invite request: v=0 o=- 0 0 IN IP s=phone-call c=in IP t=0 0 m=audio 6210 RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=ptime:20 a=sendrecv a=rtcp:6211 IN IP The SDP for redundancy will include an additional payload type in the media line (97, for example), and will also include a mapping attribute line such as: a=rtpmap:97 RED/8000 Copyright 2008 Microsoft Corporation. All rights reserved. Page 10

11 Modifying an existing voice session After a voice session is established, (the offer answer interaction has completed as specified in the preceding sections and the initial Invite transaction has completed), either side (the Enterprise Proxy or the Service Provider Proxy) may request modification to the existing session by sending a new offer. This new offer must be sent via a re Invite. The answer to such a modification request must be received in a 200 OK message. As specified in RFC 3264, either side must not generate a new offer if it has received an offer which it has not yet answered or rejected. Either side must not generate a new offer if it is awaiting an answer or rejection for a previous offer. There is a single supported scenario for modification of an audio session in Enterprise Proxy Service Provider Proxy interactions: 1. The call is put on hold or reconnected by including the appropriate media level attribute to specify send and receive characteristics Enterprise Proxy initiated modification putting calls on hold/reconnecting held calls The Enterprise Proxy will include a media level attribute in the offer that it sends in a re Invite so that a call can be placed on hold or reconnected. This media direction attribute can have values of a=sendrecv/sendonly/recvonly/inactive. The allowed values for the media direction attribute sent in the answer from the Service Provider Proxy are as specified in Section 6.1 of RFC The Enterprise Proxy will not change the port number in the media line for the audio session in the SDP offer when it sends the re Invite. The Service Provider Proxy must not change the port number in the media line for the audio session in the SDP in the answer when it responds to the re Invite with a 200 OK. Each side must abide by the agreed to media direction characteristics when sending/receiving audio Service Provider Proxy initiated modification The Service Provider Proxy must include a media level attribute in the offer that it sends in a re Invite so that a call can be placed on hold or reconnected. This media direction attribute can have values of a=sendrecv/sendonly/recvonly/inactive. The allowed values for the media direction attribute sent in the answer from the Enterprise Proxy are as specified in Section 6.1 of RFC The Service Provider Proxy must not change the port number in the media line for the audio session in the SDP in the offer when it sends the re Invite. The Enterprise Proxy will not change the port number in the media line for the audio session in the SDP in the answer when it responds to the the re Invite with a 200 OK. Each side must abide by the agreed to media direction characteristics when sending/receiving audio. For backward compatability, the Enterprise Proxy will continue to support the following scheme for putting a call on hold: Copyright 2008 Microsoft Corporation. All rights reserved. Page 11

12 The Service Provider Proxy can signal that it wishes to put a call on hold by setting the connection address in the SDP in the offer to ; the Enterprise Proxy will treat receipt of such a connection address the same way it does the receipt of a media direction attribute with a value of inactive. The Service Provider Proxy must not change the port number in the media line for the audio session in the SDP in the offer when it sends the re Invite Silence Suppression The media stack in elements of the enterprise infrastructure will often support silence suppression/voice Activity Detection in order to save network bandwidth. Therefore, there will be times during which an audio channel from the Enterprise Proxy to the Service Provider Proxy will not receive RTP packets. In order to avoid a PSTN caller hearing dead air, the Service Provider Proxy must support comfort noise generation into the PSTN side of the interface. This could happen either by the Service Provider Proxy inserting comfort noise, or the codec on the PSTN side of the gateway signaling to its peer that silence suppression is in effect, in which case the peer codec will generate comfort noise. The Service Provider Proxy MUST implement silence suppression on the RTP stream that it sends to the Enterprise Proxy. For example, the codec for the PSTN call may include signaling for silence suppression. Implementation of silence suppression in the Service Provider Proxy means that there will be times during which an audio channel from the Service Provider Proxy to the Enterprise Proxy will not receive RTP packets. In order to avoid an Enterprise endpoint hearing dead air, the media stack in such endpoints supports comfort noise generation DTMF RFC 4733 has obsoleted RFC 2833 as the standard for RTP payloads for DTMF Digits, Telephony Tones, and Telephony Signals. The interaction between the Enterprise Proxy and the Service Provider Proxy for DTMF digit interaction adheres to the RFC 2833 definition for DTMF, and thus is a subset of RFC 4733: Only DTMF Events as defined in RFC 4733 are supported on the interface between the Enterprise Proxy and the Service Provider Proxy (corresponding to a media type of audio/telephone event). Telephony tones and telephony signals (corresponding to a media type of audio/tone) are not supported. The subdivision of long events into segments, the reporting of multiple events in a single packet, and the concept and reporting of state events as defined in RFC 4733 is not supported. Event 16 for Flash continues to be supported by the Enterprise Proxy. The Service Provider Proxy must be able to detect in band DTMF in received data from the PSTN, and generate events 0 thru 16 to the Enterprise Proxy. The Service Provider Proxy must be able to receive events 0 thru 16 from the Enterprise Proxy, and generate the appropriate in band DTMF in data to the PSTN. The ptime value for named telephone event is as described earlier in this document. Copyright 2008 Microsoft Corporation. All rights reserved. Page 12

13 Inbound calls One of the payload types in the m=audio line in an incoming SDP offer for a voice call from the Service Provider Proxy to the Enterprise Proxy must be for DTMF digit exchange. Further, the events parameter associated with the telephone event media type must be included, and must indicate support for at least events An example of the relevant lines in the SDP offer is shown below: m=audio RTP/AVP a=rtpmap:101 telephone-event/8000 a=fmtp: Outbound calls The Enterprise Proxy will include a payload type for DTMF digit exchange as one of the payload types in the m=audio line in an outgoing SDP offer for a voice call from the Enterprise Proxy to the Service Provider Proxy. The events parameter associated with the telephone event media type will be included, and will indicate support for events Early media As defined in RFC 3261, SIP uses the offer/answer model for session parameter negotiation. Further, as defined in RFC 3960, an offer/answer exchange that takes place before a final response for the INVITE is sent establishes an early media session. On receipt of a 200 (OK) response, such a session transitions to a regular media session; if the final response is a non 200 class response, the early media session is terminated. Note that the Enterprise Proxy does not support the early session disposition type as defined in RFC 3959; thus, the Application Server Model as specified in RFC 3960 is not supported. Use of the Update method as specified in RFC 3311 is not supported by the Enterprise Proxy over its interface to a Service Provider Proxy Outbound calls Outgoing Invites from the Enterprise Proxy to the Service Provider Proxy will always include an SDP Offer. The Enterprise Proxy supports reliable provisional response messages as defined in RFC This is indicated via the inclusion of the 100rel option tag in the Supported header in an outgoing Invite from the Enterprise Proxy to the Service Provider Proxy. In order to establish an early media session, the Service Provider Proxy should include an SDP Answer in a reliable provisional response to the Invite. As defined in RFC 3262, only provisional responses numbered 101 to 199 may be sent reliably. In particular, the Service Provider Proxy must not attempt to send a 100 (Trying) reliably. Once the Enterprise Proxy receives the answer in a reliable provisional response, it will respond with a PRACK to signal its acceptance of the early media session. Copyright 2008 Microsoft Corporation. All rights reserved. Page 13

14 For backwards compatibility, the Enterprise Proxy will support the receipt of an SDP Answer in a nonreliable provisional response in the range from 101 to 199 in order to establish an early media session. It is up to the Service Provider Proxy vendor to decide when to negotiate early media for outgoing calls from the Enterprise Proxy, and to what extent Service Provider Proxy configuration affects the decision on whether or not to negotiate early media Inbound calls Incoming Invites from the Service Provider Proxy to the Enterprise Proxy must include an SDP Offer. In order to establish an early media session, the Enterprise Proxy may include an SDP Answer in a reliable provisional response to the Invite. If such a response is sent by the Enterprise Proxy, it will be a response in the range of 101 to 199. Once the Service Provider Proxy receives the answer in a reliable provisional response, it must respond with a PRACK to signal its acceptance of the early media session. For incoming calls from the Service Provider Proxy to the Enterprise Proxy (the Invite is sent to the Enterprise Proxy), the Enterprise Proxy could negotiate early media so as to enable the send stream from the Service Provider Proxy to the Enterprise Proxy before the call goes active. In this scenario, the Service Provider Proxy can be ready to receive media as soon as it sends the Invite to the Enterprise Proxy. Note that cases where early media could be requested by the Enterprise Proxy include: Hairpin calls in the Enterprise Proxy or between Enterprise Proxies, caused, for example, by an incoming call to an enterprise user being forwarded back out to the PSTN. Clients in the enterprise network attempting to negotiate early media Address formatting Inbound calls SIP URIs must be used in incoming Invites from the Service Provider Proxy to the Enterprise Proxy. All such SIP URIs should be tel URIs as specified in RFC 3966 that have been converted to SIP URIs using the conversion rules in RFC All such SIP URIs must have a user parameter with a value of phone (user=phone). The SIP URIs provided by the Service Provider Proxy in the Request URI, From header, and To header for incoming Invites from the Service Provider Proxy to the Enterprise Proxy should contain an E.164 number whenever possible. If these fields do not contain an E.164 number, the Enterprise Proxy will perform address conversions before forwarding the Invite to the rest of the Enterprise network. Examples of SIP URIs received by the Enterprise Proxy from a Service Provider Proxy: INVITE sip: @s1.ms.com;user=phone Copyright 2008 Microsoft Corporation. All rights reserved. Page 14

15 From: To: INVITE From: To: s1.ms.com;user=phone> INVITE From: To: s1.ms.com;user=phone> Note: g1.contoso.com and s1.ms.com (which are FQDNs) may be replaced with an IP address or domain Address manipulation before an Invite is forwarded to the Enterprise infrastructure This section describes how the Enterprise Proxy processes and changes addressing fields in an incoming Invite received from a Service Provider Proxy before it forwards the Invite to the Enterprise Infrastructure; this is part of the processing done by the Enterprise Proxy in its role as a B2BUA. For the Request URI and To header fields, if the SIP URI does not contain an E.164 number and does not contain a phone context parameter, and does contain a user=phone parameter, the Enterprise Proxy will insert a phone context parameter before part of the SIP URI; the value of this parameter will correspond to the value associated with the scope of validity of the number, for example, the local domain. (This is done so that when the Invite is presented to the Enterprise Infrastructure, the number can be converted to an E.164 number if possible, or to some private numbering plan if conversion to an E.164 number is not possible.) If the SIP URI does not contain an E.164 number and does contain a phone context parameter, it will be passed through unmodified. If the SIP URI does not contain a user=phone parameter, or contains a user=phone parameter but there is no numeric string before the start of the parameter values before part of the URI, the incoming Invite will be rejected via a final message. For the From header field, if the SIP URI does not contain an E.164 number and does not contain a phone context parameter, the Enterprise Proxy will insert a phone context parameter before part of the SIP URI with a value of unknown. If the SIP URI does not contain an E.164 number and does contain a phone context parameter, it will be passed through unmodified. If the SIP URI does not contain a user=phone parameter or is missing the user part, it will be converted to the SIP URI that denotes an anonymous user as specified next Outbound calls SIP URIs will be used in outgoing Invites from the Enterprise Proxy to the Service Provider Proxy. Copyright 2008 Microsoft Corporation. All rights reserved. Page 15

16 The Enterprise Proxy will send a Service Provider Proxy one of the following URI formats in SIP Request URI and To headers: 1. SIP URI with E.164 phone number: sip: @g1.contoso.com;user=phone 2. SIP URI with a unique extension within the enterprise: sip:51234@g1.contoso.com;user=phone 3. SIP URI with a phone context parameter: sip: ;phone context=redmond@g1.contoso.com;user=phone sip:911;phone context=redmond@g1.contoso.com;user =phone sip:911;phone context=+1@g1.contosco.com;user=phone Note: g1.contoso.com (which is an FQDN) may be replaced with an IP address or domain. The Enterprise Proxy will send a Service Provider Proxy one of the following URI formats in the SIP From header: SIP URI with E.164 phone number: sip: @s1.ms.com;user=phone SIP URI with a global unique extension within the enterprise: sip:51234@s1.ms.com;user=phone SIP URI with alias name (in case the caller does not have or is not willing to expose a phone number): sip:alice@ms.com SIP URI with anonymous encoding: anonymous@ms.com; user=phone Note: s1.ms.com (which is an FQDN) may be replaced with an IP address or domain Service Provider Proxy failover and error scenarios The communications between the Service Provider Proxy and the Enterprise Proxy must signal overload and error conditions via a 503 Service Unavailable response message Outbound calls When the Service Provider Proxy receives an Invite for an outgoing call from the Enterprise Proxy, and it subsequently determines that it cannot handle the Invite due to resource exhaustion or some other resource constraints, it should respond to the Invite with a 503 Service Unavailable response message. Such a response, when sent back to signal resource constraint in the Service Provider Proxy, may be sent back after a 100 Trying provisional response. The Service Provider Proxy must not send a provisional response in the range from 101 to 199 before a 503 response sent to signal resource constraint in the Service Provider Proxy. The following are examples of resource constraint in the Service Provider Proxy that should result in a 503 response being sent back to the Enterprise Proxy: Copyright 2008 Microsoft Corporation. All rights reserved. Page 16

17 Insufficient processor or memory capacity to handle a new call Failed components for example, major error conditions in transmission facilities, etc. which mean that no new calls can be routed through the Service Provider Proxy Inbound calls The Service Provider Proxy may have the ability to support multiple next hop elements. When the Service Provider Proxy receives a 503 Service Unavailable response from the Enterprise Proxy, it may try any alternate Enterprise Proxy that is provisioned. The Service Provider Proxy should periodically retry the original Enterprise Proxy by sending new calls to it to detect the possibility that the anomaly condition has been cleared Management and default mappings The Service Provider Proxy is managed via its native set of network management tools that is independent of the Enterprise management infrastructure. There will be a variety of configuration parameters corresponding to the PSTN and Enterprise sides of the Service Provider Proxy. This section will discuss a few configurable parameters on the Service Provider Proxy pertinent to its interactions with the Enterprise Proxy. The Service Provider Proxy must have parameters that define the set of Enterprise Proxies that it can communicate with. For each such Enterprise Proxy, there must be parameters that allow for the definition of the FQDN and Port used to communicate with that Enterprise Proxy; alternatively, an IP Address and Port can be used. Note that the FQDN or IP address will also be used to populate the host portion of the SIP URI in the Request URI and To header fields of an Invite from the Service Provider Proxy to the Enterprise Proxy Globalization / localization For the purposes of interoperability, it is important to adhere to the augmented BNF for the SIP protocol as defined in RFC 3261, and other referenced RFCs such as RFC 2279 on UTF 8, RFC 2396 on URI syntax, RFC 2822 on Internet Message Format, etc. This means that care should be taken, for example, to make sure that SIP specific header values and parameters that are defined as being ASCII don t contain non ASCII UTF 8 or country specific characters, or that country specific character encodings that conflict with UTF 8 are not used in UTF 8 fields. 4.2 Function specific requirements NOTE: The diagrams presented in this section are for illustrative purposes only. They are not meant to be an exhaustive enumeration of all possible cases (and, in particular, do not illustrate error cases) and are not meant to replace equivalent diagrams in the applicable IETF RFCs and Drafts. Although every effort is made to ensure correctness, in cases where they conflict/ contradict the applicable IETF RFCs and Drafts, the IETF documents should be assumed to be the correct ones. Copyright 2008 Microsoft Corporation. All rights reserved. Page 17

18 4.2.1 Outbound call with Early Media Enterprise Proxy Service Provider Proxy (1) Invite (2) 100 Trying (3) 183 Progress (4) PRACK (5) 200 OK Early Media (RTP G.711 u-law, DTMF) (6) 200 OK (7) ACK Figure 1: Outbound call from Enterprise Proxy; Service Provider Proxy negotiates Early Media This example covers a call initiated from within the Enterprise network to the PSTN network. In this example, early media is negotiated by the Service Provider Proxy to the Enterprise Proxy. An example of the messaging between the Enterprise Proxy (EP) and the Service Provider Proxy (SPP) is provided below: 1. Invite (EP >SPP) INVITE sip: @ ;user=phone SIP/2.0 FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone> CSEQ: 2 INVITE CALL-ID: b28b c-a2ca-ab0b MAX-FORWARDS: 70 VIA: SIP/2.0/TCP :4623;branch=z9hG4bK14f6d8e0 Copyright 2008 Microsoft Corporation. All rights reserved. Page 18

19 CONTACT: <sip:n17-lct.contosco.com:5060;transport=tcp;maddr= ;msopaque=2e22c31eddd00a35> CONTENT-LENGTH: 305 SUPPORTED: 100rel USER-AGENT: RTCC/ MediationServer CONTENT-TYPE: application/sdp; charset=utf-8 ALLOW: Ack, Cancel, Bye, Invite, Prack v=0 o=- 0 0 IN IP s=session c=in IP b=ct:1000 t=0 0 m=audio RTP/AVP c=in IP a=rtcp:60423 a=label:audio a=rtpmap:97 RED/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=ptime:20 2. Trying (SPP >EP) SIP/ Trying FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone>;tag=1c CSEQ: 2 INVITE CALL-ID: b28b c-a2ca-ab0b VIA: SIP/2.0/TCP :4623;branch=z9hG4bK14f6d8e0 CONTENT-LENGTH: 0 ALLOW: INVITE,ACK,CANCEL,BYE,PRACK SERVER: PSTN Gateway 3. Progress (SPP >EP) Note that this message contains an SDP, so it is a request for early media. Notice the Require: 100rel header used to assert that the response should be a PRACK. This is the exchange that should be used to establish an early media session. SIP/ Session Progress FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone>;tag=1c CSEQ: 2 INVITE CALL-ID: b28b c-a2ca-ab0b VIA: SIP/2.0/TCP :4623;branch=z9hG4bK14f6d8e0 CONTACT: <sip:1113@ ;user=phone;transport=tcp> CONTENT-LENGTH: 270 Copyright 2008 Microsoft Corporation. All rights reserved. Page 19

20 CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,CANCEL,BYE,PRACK REQUIRE: 100rel SERVER: PSTN Gateway RSeq: 1 v=0 o=pstn_gateway IN IP s=phone-call c=in IP t=0 0 m=audio 6130 RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=ptime:20 a=sendrecv a=rtcp:6131 IN IP PRACK (EP >SPP) PRACK sip:1113@ ;user=phone;transport=tcp SIP/2.0 FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone>;tag=1c CSEQ: 3 PRACK CALL-ID: b28b c-a2ca-ab0b MAX-FORWARDS: 70 VIA: SIP/2.0/TCP :4623;branch=z9hG4bKaf183e59 CONTENT-LENGTH: 0 USER-AGENT: RTCC/ MediationServer RAck: 1 2 INVITE OK (SPP >EP). This is for the PRACK transaction. SIP/ OK FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone>;tag=1c CSEQ: 3 PRACK CALL-ID: b28b c-a2ca-ab0b VIA: SIP/2.0/TCP :4623;branch=z9hG4bKaf183e59 CONTACT: <sip:1113@ ;user=phone;transport=tcp> CONTENT-LENGTH: 0 SUPPORTED: 100rel ALLOW: INVITE,ACK,CANCEL,BYE,PRACK SERVER: PSTN Gateway OK (SPP >EP). This is for the Invite transaction. SIP/ OK Copyright 2008 Microsoft Corporation. All rights reserved. Page 20

21 FROM: LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: CSEQ: 2 INVITE CALL-ID: b28b c-a2ca-ab0b VIA: SIP/2.0/TCP :4623;branch=z9hG4bK14f6d8e0 CONTACT: <sip:1113@ ;user=phone;transport=tcp> SUPPORTED: 100rel ALLOW: INVITE,ACK,CANCEL,BYE,PRACK SERVER: PSTN Gateway 7. ACK (EP >SPP) ACK sip:1113@ ;user=phone;transport=tcp SIP/2.0 FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone>;tag=1c CSEQ: 2 ACK CALL-ID: b28b c-a2ca-ab0b MAX-FORWARDS: 70 VIA: SIP/2.0/TCP :4623;branch=z9hG4bKf5f4498 CONTENT-LENGTH: 0 USER-AGENT: RTCC/ MediationServer Copyright 2008 Microsoft Corporation. All rights reserved. Page 21

22 4.2.2 Call placed on Hold by Enterprise network and then reconnected Enterprise Proxy Service Provider Proxy Send-Receive RTP (1) Invite (2) 200 OK (3) ACK [Inactive] (4) Invite (5) 200 OK (6) ACK Send-Receive RTP Figure 2: Active call placed on Hold and then reconnected This example covers the interactions that occur when an Enterprise user places the call on hold and then reconnects the held call. The traces below are for the same call that was initiated from the Enterprise network for which traces were provided in the preceding section; the dialog ID will match the one for the traces in the previous section. An example of the messaging between the Enterprise Proxy (EP) and the Service Provider Proxy (SPP) is provided below: 1. Invite (EP >SPP) This re Invite has an a=inactive direction attribute to denote that the send and receive directions are both to be made inactive.] INVITE SIP/2.0 FROM: LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: CSEQ: 4 INVITE CALL-ID: b28b c-a2ca-ab0b MAX-FORWARDS: 70 VIA: SIP/2.0/TCP :4623;branch=z9hG4bK93c9eac9 CONTACT: <sip:n17-lct.contosco.com:5060;transport=tcp;maddr= ;msopaque=2e22c31eddd00a35> CONTENT-LENGTH: 268 Copyright 2008 Microsoft Corporation. All rights reserved. Page 22

23 SUPPORTED: 100rel USER-AGENT: RTCC/ MediationServer CONTENT-TYPE: application/sdp; charset=utf-8 v=0 o=- 0 0 IN IP s=session c=in IP b=ct:1000 t=0 0 m=audio RTP/AVP c=in IP a=rtcp:60423 a=inactive a=label:audio a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=ptime: OK (SPP >EP) SIP/ OK FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone>;tag=1c CSEQ: 4 INVITE CALL-ID: b28b c-a2ca-ab0b VIA: SIP/2.0/TCP :4623;branch=z9hG4bK93c9eac9 CONTACT: <sip:1113@ ;user=phone;transport=tcp> CONTENT-LENGTH: 270 SUPPORTED: 100rel CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,CANCEL,BYE,PRACK SERVER: PSTN Gateway v=0 o=pstn_gateway IN IP s=phone-call c=in IP t=0 0 m=audio 6130 RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=ptime:20 a=inactive a=rtcp:6131 IN IP ACK (EP >SPP) ACK sip:1113@ ;user=phone;transport=tcp SIP/2.0 FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e Copyright 2008 Microsoft Corporation. All rights reserved. Page 23

24 TO: CSEQ: 4 ACK CALL-ID: b28b c-a2ca-ab0b MAX-FORWARDS: 70 VIA: SIP/2.0/TCP :4623;branch=z9hG4bK184a5a51 CONTENT-LENGTH: 0 USER-AGENT: RTCC/ MediationServer Receive, Send streams are now inactive. 4. Invite (EP >SPP) The client in the Enterprise network wishes to reconnect the held call; note that the lack of a direction attribute is equivalent to a=sendrecv] INVITE sip:1113@ ;user=phone;transport=tcp SIP/2.0 FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone>;tag=1c CSEQ: 5 INVITE CALL-ID: b28b c-a2ca-ab0b MAX-FORWARDS: 70 VIA: SIP/2.0/TCP :4623;branch=z9hG4bK5e8925a7 CONTACT: <sip:n17-lct.contosco.com:5060;transport=tcp;maddr= ;msopaque=2e22c31eddd00a35> CONTENT-LENGTH: 256 SUPPORTED: 100rel USER-AGENT: RTCC/ MediationServer CONTENT-TYPE: application/sdp; charset=utf-8 v=0 o=- 0 0 IN IP s=session c=in IP b=ct:1000 t=0 0 m=audio RTP/AVP c=in IP a=rtcp:60423 a=label:audio a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=ptime: OK [SPP >EP] SIP/ OK FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone>;tag=1c CSEQ: 5 INVITE CALL-ID: b28b c-a2ca-ab0b VIA: SIP/2.0/TCP :4623;branch=z9hG4bK5e8925a7 Copyright 2008 Microsoft Corporation. All rights reserved. Page 24

25 CONTACT: CONTENT-LENGTH: 270 SUPPORTED: 100rel CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,CANCEL,BYE,PRACK SERVER: PSTN Gateway v=0 o=pstn_gateway IN IP s=phone-call c=in IP t=0 0 m=audio 6130 RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=ptime:20 a=sendrecv a=rtcp:6131 IN IP ACK [EP >SPP] ACK sip:1113@ ;user=phone;transport=tcp SIP/2.0 FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone>;tag=1c CSEQ: 5 ACK CALL-ID: b28b c-a2ca-ab0b MAX-FORWARDS: 70 VIA: SIP/2.0/TCP :4623;branch=z9hG4bKb9902d9f CONTENT-LENGTH: 0 USER-AGENT: RTCC/ MediationServer Active call is disconnected Enterprise Proxy Service Provider Proxy Send-Receive RTP (1) Bye (2) 200 OK Figure 3: Active call cleared Copyright 2008 Microsoft Corporation. All rights reserved. Page 25

26 This example covers the clearing of an active call, where the Enterprise user initiates the call clearing. The traces below are for the same call that was initiated from the Enterprise network for which traces were provided in the preceding section; the dialog ID will match the one for the traces in the previous sections. An example of the messaging between the Enterprise Proxy (EP) and the Service Provider Proxy (SPP) is provided below: 1. Bye (EP >SPP) BYE SIP/2.0 FROM: LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: CSEQ: 6 BYE CALL-ID: b28b c-a2ca-ab0b MAX-FORWARDS: 70 VIA: SIP/2.0/TCP :4623;branch=z9hG4bK1be341ea CONTENT-LENGTH: 0 USER-AGENT: RTCC/ MediationServer OK (SPP >EP) SIP/ OK FROM: <sip: @n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip: @ ;user=phone>;tag=1c CSEQ: 6 BYE CALL-ID: b28b c-a2ca-ab0b VIA: SIP/2.0/TCP :4623;branch=z9hG4bK1be341ea CONTACT: <sip:1113@ ;user=phone;transport=tcp> CONTENT-LENGTH: 0 SUPPORTED: 100rel ALLOW: INVITE,ACK,CANCEL,BYE,PRACK SERVER: PSTN Gateway Copyright 2008 Microsoft Corporation. All rights reserved. Page 26

27 4.2.4 Inbound call Enterprise Proxy Service Provider Proxy (1) Invite (2) 100 Trying (3) 183 Progress (4) 180 Ringing (5) 200 OK (7) ACK (RTP G.711 u-law, DTMF) Figure 4: Inbound call establishment This example covers an inbound call from the PSTN to the Enterprise network. An example of the messaging between the Enterprise Proxy (EP) and the Service Provider Proxy (SPP) is provided below: 1. Invite (SPP >EP) INVITE SIP/2.0 FROM: " " TO: CSEQ: 1 INVITE CALL-ID: @ MAX-FORWARDS: 70 VIA: SIP/2.0/TCP ;branch=z9hG4bKac ;alias Copyright 2008 Microsoft Corporation. All rights reserved. Page 27