Microsoft s Proposal to the SIP Forum For SIP Trunking Interoperability SIPConnect v2.0 April 2008 Copyright 2008 Microsoft Corporation. All rights reserved. Page 1
1. Introduction...3 1.1 Requirement levels... 3 1.2 Goals... 3 1.3 Non-Goals... 3 1.4 Scenarios... 4 2. Architecture...4 3. Protocol Flow and Procedures...5 3.1 Service Provider Proxy Discovery Static Provisioning... 5 3.2 Enterprise Proxy Discovery... 5 3.3 Connection Establishment and Management... 6 3.3.1 Variant 1 IP VPN... 6 3.3.2 Variant 2 TLS and SRTP... 6 4. Requirements for interfacing with the Enterprise Proxy...7 4.1 General requirements... 7 4.1.1 SIP over TCP... 7 4.1.2 DNS support... 7 4.1.3 IPv4 support... 7 4.1.4 Media processing... 7 4.1.5 Voice calls... 8 4.1.6 Early media...13 4.1.7 Address formatting...14 4.1.8 Service Provider Proxy failover and error scenarios...16 4.1.9 Management and default mappings...17 4.1.10 Globalization / localization...17 4.2 Function specific requirements... 17 4.2.1 Outbound call with Early Media...18 4.2.2 Call placed on Hold by Enterprise network and then reconnected...22 4.2.3 Active call is disconnected...25 4.2.4 Inbound call...27 4.3 SIP support summary... 30 4.3.1 Functions...30 4.3.2 Methods...30 4.3.3 Headers...31 4.3.4 Responses...33 Copyright 2008 Microsoft Corporation. All rights reserved. Page 2
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
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
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
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. 3.3.1 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. 3.3.2 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
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. 4.1.1 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. 4.1.2 DNS support The Service Provider Proxy MUST be able to translate host names to IP addresses using DNS (Domain Name Service) servers. 4.1.3 IPv4 support The Enterprise Proxy MUST support IPv4 and MAY support IPv6. The Service Provider Proxy MUST support IPv4. 4.1.4 Media processing The Service Provider Proxy needs to follow the media processing requirements defined in the following sections. 4.1.4.1 General The Service Provider Proxy: Copyright 2008 Microsoft Corporation. All rights reserved. Page 7
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. 4.1.4.2 Echo cancellation Echo cancellation MUST be supported. 4.1.4.3 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. 4.1.5 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. 4.1.5.1 Offer answer model for voice calls This section covers the offer/answer model for voice calls. 4.1.5.1.1 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 0.0.0.0 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
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 2198. 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. 4.1.5.1.2 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 0.0.0.0 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
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 2198. 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. 4.1.5.1.3 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 IP4 172.29.107.252 s=phone-call c=in IP4 172.29.107.252 t=0 0 m=audio 6210 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv a=rtcp:6211 IN IP4 172.29.107.252 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
4.1.5.1.4 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. 4.1.5.1.5 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 3264. 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. 4.1.5.1.6 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 3264. 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
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 0.0.0.0; 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. 4.1.5.2 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. 4.1.5.3 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
4.1.5.3.1 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 0 16. An example of the relevant lines in the SDP offer is shown below: m=audio 60632 RTP/AVP 101 0 8 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 4.1.5.3.2 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 0 16. 4.1.6 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. 4.1.6.1 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 3262. 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
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. 4.1.6.2 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. 4.1.7 Address formatting 4.1.7.1 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 3261. 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:+14257123456@s1.ms.com;user=phone Copyright 2008 Microsoft Corporation. All rights reserved. Page 14
From: <sip:+14257654321@g1.contoso.com;user=phone> To: sip:+14257123456@s1.ms.com;user=phone INVITE sip:51234@s1.ms.com;user=phone From: <sip:+14257654321@g1.contoso.com;user=phone> To: <sip:51234@ s1.ms.com;user=phone> INVITE sip:51234;phone-context=xyz@s1.ms.com;user=phone From: <sip:+14257654321@g1.contoso.com;user=phone> To: <sip:51234;phone-context=xyz@ 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. 4.1.7.1.1 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 the @host 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 the @host 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 the @host 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. 4.1.7.2 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
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:+14257123456@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:4151211;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:+14257123456@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. 4.1.8 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. 4.1.8.1 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
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 4.1.8.2 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. 4.1.9 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. 4.1.10 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
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:+14257123456@172.29.107.252;user=phone SIP/2.0 FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone> CSEQ: 2 INVITE CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bK14f6d8e0 Copyright 2008 Microsoft Corporation. All rights reserved. Page 18
CONTACT: <sip:n17-lct.contosco.com:5060;transport=tcp;maddr=172.29.105.23;msopaque=2e22c31eddd00a35> CONTENT-LENGTH: 305 SUPPORTED: 100rel USER-AGENT: RTCC/3.0.0.0 MediationServer CONTENT-TYPE: application/sdp; charset=utf-8 ALLOW: Ack, Cancel, Bye, Invite, Prack v=0 o=- 0 0 IN IP4 172.29.105.23 s=session c=in IP4 172.29.105.23 b=ct:1000 t=0 0 m=audio 60422 RTP/AVP 97 101 0 8 c=in IP4 172.29.105.23 a=rtcp:60423 a=label:audio a=rtpmap:97 RED/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=ptime:20 2. Trying (SPP >EP) SIP/2.0 100 Trying FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 2 INVITE CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 VIA: SIP/2.0/TCP 172.29.105.23: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/2.0 183 Session Progress FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 2 INVITE CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bK14f6d8e0 CONTACT: <sip:1113@172.29.107.252;user=phone;transport=tcp> CONTENT-LENGTH: 270 Copyright 2008 Microsoft Corporation. All rights reserved. Page 19
CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,CANCEL,BYE,PRACK REQUIRE: 100rel SERVER: PSTN Gateway RSeq: 1 v=0 o=pstn_gateway 804627327 804627048 IN IP4 172.29.107.252 s=phone-call c=in IP4 172.29.107.252 t=0 0 m=audio 6130 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv a=rtcp:6131 IN IP4 172.29.107.252 4. PRACK (EP >SPP) PRACK sip:1113@172.29.107.252;user=phone;transport=tcp SIP/2.0 FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 3 PRACK CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bKaf183e59 CONTENT-LENGTH: 0 USER-AGENT: RTCC/3.0.0.0 MediationServer RAck: 1 2 INVITE 5. 200 OK (SPP >EP). This is for the PRACK transaction. SIP/2.0 200 OK FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 3 PRACK CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bKaf183e59 CONTACT: <sip:1113@172.29.107.252;user=phone;transport=tcp> CONTENT-LENGTH: 0 SUPPORTED: 100rel ALLOW: INVITE,ACK,CANCEL,BYE,PRACK SERVER: PSTN Gateway 6. 200 OK (SPP >EP). This is for the Invite transaction. SIP/2.0 200 OK Copyright 2008 Microsoft Corporation. All rights reserved. Page 20
FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 2 INVITE CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bK14f6d8e0 CONTACT: <sip:1113@172.29.107.252;user=phone;transport=tcp> SUPPORTED: 100rel ALLOW: INVITE,ACK,CANCEL,BYE,PRACK SERVER: PSTN Gateway 7. ACK (EP >SPP) ACK sip:1113@172.29.107.252;user=phone;transport=tcp SIP/2.0 FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 2 ACK CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bKf5f4498 CONTENT-LENGTH: 0 USER-AGENT: RTCC/3.0.0.0 MediationServer Copyright 2008 Microsoft Corporation. All rights reserved. Page 21
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:1113@172.29.107.252;user=phone;transport=tcp SIP/2.0 FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 4 INVITE CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bK93c9eac9 CONTACT: <sip:n17-lct.contosco.com:5060;transport=tcp;maddr=172.29.105.23;msopaque=2e22c31eddd00a35> CONTENT-LENGTH: 268 Copyright 2008 Microsoft Corporation. All rights reserved. Page 22
SUPPORTED: 100rel USER-AGENT: RTCC/3.0.0.0 MediationServer CONTENT-TYPE: application/sdp; charset=utf-8 v=0 o=- 0 0 IN IP4 172.29.105.23 s=session c=in IP4 172.29.105.23 b=ct:1000 t=0 0 m=audio 60422 RTP/AVP 0 101 c=in IP4 172.29.105.23 a=rtcp:60423 a=inactive a=label:audio a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 2. 200 OK (SPP >EP) SIP/2.0 200 OK FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 4 INVITE CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bK93c9eac9 CONTACT: <sip:1113@172.29.107.252;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 804627327 804627048 IN IP4 172.29.107.252 s=phone-call c=in IP4 172.29.107.252 t=0 0 m=audio 6130 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=inactive a=rtcp:6131 IN IP4 172.29.107.252 3. ACK (EP >SPP) ACK sip:1113@172.29.107.252;user=phone;transport=tcp SIP/2.0 FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e Copyright 2008 Microsoft Corporation. All rights reserved. Page 23
TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 4 ACK CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bK184a5a51 CONTENT-LENGTH: 0 USER-AGENT: RTCC/3.0.0.0 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@172.29.107.252;user=phone;transport=tcp SIP/2.0 FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 5 INVITE CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bK5e8925a7 CONTACT: <sip:n17-lct.contosco.com:5060;transport=tcp;maddr=172.29.105.23;msopaque=2e22c31eddd00a35> CONTENT-LENGTH: 256 SUPPORTED: 100rel USER-AGENT: RTCC/3.0.0.0 MediationServer CONTENT-TYPE: application/sdp; charset=utf-8 v=0 o=- 0 0 IN IP4 172.29.105.23 s=session c=in IP4 172.29.105.23 b=ct:1000 t=0 0 m=audio 60422 RTP/AVP 0 101 c=in IP4 172.29.105.23 a=rtcp:60423 a=label:audio a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 5. 200 OK [SPP >EP] SIP/2.0 200 OK FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 5 INVITE CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bK5e8925a7 Copyright 2008 Microsoft Corporation. All rights reserved. Page 24
CONTACT: <sip:1113@172.29.107.252;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 804627327 804627048 IN IP4 172.29.107.252 s=phone-call c=in IP4 172.29.107.252 t=0 0 m=audio 6130 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv a=rtcp:6131 IN IP4 172.29.107.252 6. ACK [EP >SPP] ACK sip:1113@172.29.107.252;user=phone;transport=tcp SIP/2.0 FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 5 ACK CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bKb9902d9f CONTENT-LENGTH: 0 USER-AGENT: RTCC/3.0.0.0 MediationServer 4.2.3 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
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:1113@172.29.107.252;user=phone;transport=tcp SIP/2.0 FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 6 BYE CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bK1be341ea CONTENT-LENGTH: 0 USER-AGENT: RTCC/3.0.0.0 MediationServer 2. 200 OK (SPP >EP) SIP/2.0 200 OK FROM: <sip:+14257234567@n17- LCT.contosco.com;user=phone>;epid=8E90067BA0;tag=12c5e6855e TO: <sip:+14257123456@172.29.107.252;user=phone>;tag=1c804539759 CSEQ: 6 BYE CALL-ID: b28b5949-9047-475c-a2ca-ab0b57111796 VIA: SIP/2.0/TCP 172.29.105.23:4623;branch=z9hG4bK1be341ea CONTACT: <sip:1113@172.29.107.252;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
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:7273345@172.29.105.23;user=phone SIP/2.0 FROM: "3003019411" <sip:3003019411@172.29.107.252;user=phone>;tag=1c1096230356 TO: <sip:7273345@172.29.105.23;user=phone> CSEQ: 1 INVITE CALL-ID: 10962295921222000224122@172.29.107.252 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.29.107.252;branch=z9hG4bKac1096245824;alias Copyright 2008 Microsoft Corporation. All rights reserved. Page 27
CONTACT: <sip:3003019411@172.29.107.252;user=phone;transport=tcp> CONTENT-LENGTH: 416 SUPPORTED: 100rel USER-AGENT: PSTN Gateway CONTENT-TYPE: application/sdp ALLOW: INVITE,ACK,CANCEL,BYE,PRACK CONTENT-DISPOSITION: session v=0 o= PSTN_Gateway 1096204542 1096204255 IN IP4 172.29.107.252 s=phone-call c=in IP4 172.29.107.252 t=0 0 m=audio 6210 RTP/AVP 0 8 18 4 23 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:4 G723/8000 a=fmtp:4 annexa=no a=rtpmap:23 G726-16/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv a=rtcp:6211 IN IP4 172.29.107.252 2. Trying (EP >SPP) SIP/2.0 100 Trying FROM: "3003019411"<sip:3003019411@172.29.107.252;user=phone>;tag=1c1096230356 TO: <sip:7273345@172.29.105.23;user=phone> CSEQ: 1 INVITE CALL-ID: 10962295921222000224122@172.29.107.252 VIA: SIP/2.0/TCP 172.29.107.252;branch=z9hG4bKac1096245824;alias CONTENT-LENGTH: 0 3. 183 Progress (EP >SPP) SIP/2.0 183 Session Progress FROM: "3003019411"<sip:3003019411@172.29.107.252;user=phone>;tag=1c1096230356 TO: <sip:7273345@172.29.105.23;user=phone>;epid=8e90067ba0;tag=4d9da4b1f CSEQ: 1 INVITE CALL-ID: 10962295921222000224122@172.29.107.252 VIA: SIP/2.0/TCP 172.29.107.252;branch=z9hG4bKac1096245824;alias CONTENT-LENGTH: 0 SERVER: RTCC/3.0.0.0 MediationServer 4. 180 Ringing (EP >SPP) SIP/2.0 180 Ringing FROM: "3003019411"<sip:3003019411@172.29.107.252;user=phone>;tag=1c1096230356 TO: <sip:7273345@172.29.105.23;user=phone>;epid=8e90067ba0;tag=4d9da4b1f Copyright 2008 Microsoft Corporation. All rights reserved. Page 28
CSEQ: 1 INVITE CALL-ID: 10962295921222000224122@172.29.107.252 VIA: SIP/2.0/TCP 172.29.107.252;branch=z9hG4bKac1096245824;alias CONTENT-LENGTH: 0 SERVER: RTCC/3.0.0.0 MediationServer 5. 200 OK (EP >SPP) SIP/2.0 200 OK FROM: "3003019411"<sip:3003019411@172.29.107.252;user=phone>;tag=1c1096230356 TO: <sip:7273345@172.29.105.23;user=phone>;epid=8e90067ba0;tag=4d9da4b1f CSEQ: 1 INVITE CALL-ID: 10962295921222000224122@172.29.107.252 VIA: SIP/2.0/TCP 172.29.107.252;branch=z9hG4bKac1096245824;alias CONTACT: <sip: N17-LCT.contosco.com:5060;transport=Tcp;maddr=172.29.105.23> CONTENT-LENGTH: 256 SUPPORTED: 100rel CONTENT-TYPE: application/sdp; charset=utf-8 SERVER: RTCC/3.0.0.0 MediationServer ALLOW: Ack, Cancel, Bye, Invite, Prack v=0 o=- 0 0 IN IP4 172.29.105.23 s=session c=in IP4 172.29.105.23 b=ct:1000 t=0 0 m=audio 63214 RTP/AVP 0 101 c=in IP4 172.29.105.23 a=rtcp:63215 a=label:audio a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 6. ACK (SPP >EP) ACK sip: N17-LCT.contosco.com:5060;transport=Tcp;maddr=172.29.105.23 SIP/2.0 FROM: "3003019411" <sip:3003019411@172.29.107.252;user=phone>;tag=1c1096230356 TO: <sip:7273345@172.29.105.23;user=phone>;epid=8e90067ba0;tag=4d9da4b1f CSEQ: 1 ACK CALL-ID: 10962295921222000224122@172.29.107.252 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.29.107.252;branch=z9hG4bKac1271917058;alias CONTACT: <sip:3003019411@172.29.107.252;user=phone;transport=tcp> CONTENT-LENGTH: 0 SUPPORTED: 100rel USER-AGENT: PSTN Gateway ALLOW: INVITE,ACK,CANCEL,BYE,PRACK Copyright 2008 Microsoft Corporation. All rights reserved. Page 29
4.3 SIP support summary The following tables summarize the aspects of compliance with the relevant SIP RFCs that a Service Provider Proxy needs to meet in order to interoperate with the Enterprise Network. The tables below use the following definitions: Components a) EP refers to the Enterprise Proxy component of the Enterprise network. b) SPP refers to the Service Provider Proxy. Type of support: a) GEN it refers to the ability of the component to generate the applicable SIP element (method, header, function) when appropriate b) REC it refers to the ability of the component to receive and process the applicable SIP element (method, header, function) when appropriate The usage of the keywords Must, Should, May, Not Recommended (NR) are as defined in the Requirements levels section at the beginning of this document. 4.3.1 Functions Function SPP EP Comments User Agent Client (UAC) MUST Yes User Agent Server (UAS) MUST Yes Proxy Server No No Redirect Server No No Registrar No No 4.3.2 Methods Methods SPP GEN SPP REC EP Comments ACK MUST MUST Yes BYE MUST MUST Yes CANCEL MUST MUST Yes INFO NR NR No RFC 2976 INVITE MUST MUST Yes MESSAGE NR NR No RFC 3428 NOTIFY NR NR No RFC 3265. OPTIONS NR NR No Copyright 2008 Microsoft Corporation. All rights reserved. Page 30
Methods SPP GEN SPP REC EP Comments PRACK MUST MUST Yes RFC 3262 PUBLISH NR NR No RFC ietf sip publish 04.txt REFER NR NR No RFC 3515. REGISTER NR NR No SUBSCRIBE NR NR No RFC 3265 UPDATE NR NR No RFC 3311 4.3.3 Headers Headers SPP GEN SPP REC Comments Accept SHOULD SHOULD Accept Contact NR NR RFC ietf sip callerprefs 10.txt Accept Encoding SHOULD SHOULD Accept Language SHOULD SHOULD Alert Info MAY MAY Allow SHOULD SHOULD Allow Events MAY MAY RFC 3265 Also NR NR Authentication Info NR NR Authorization NR NR Call ID MUST MUST Call Info MAY MAY Contact MUST MUST Content Disposition MAY MAY Content Encoding SHOULD SHOULD Content Language MAY MAY Content Length MUST MUST Content Type MUST MUST Cseq MUST MUST Date MAY MAY Diversion NR NR Encryption NR NR RFC 3261. deprecated according to IANA Event NR NR Expires SHOULD SHOULD Fax NR NR This may be proprietary From MUST MUST Hide NR NR RFC 3261. deprecated according to IANA History Info NR NR In Reply To NR NR Join NR NR RFC ietf sip join 03.txt Copyright 2008 Microsoft Corporation. All rights reserved. Page 31
Headers SPP GEN SPP REC Comments Max Forwards MUST MUST MIME version MAY MAY Min Expires NR NR Min SE SHOULD MAY Organization MAY MAY P Access Network Info NR NR RFC 3455 P Asserted Identity NR NR RFC 3325 P Associated URI NR NR RFC 3455 P Called Party ID NR NR RFC 3455 P Charging Function Addresses NR NR RFC 3455 P Charging Vector NR NR RFC 3455 P DCS Trace Party ID NR NR RFC 3603 P DCS OSPS NR NR RFC 3603 P DCS Billing Info NR NR RFC 3603 P DCS LAES NR NR RFC 3603 P DCS Redirect NR NR RFC 3603 P Media Authorization NR NR RFC 3313 P Preferred Identity NR NR RFC 3325 P Visited Network ID NR NR RFC 3455 Path NR NR RFC 3327 Priority MAY MAY Privacy MAY MAY RFC 3323 Proxy Authenticate NR NR Proxy Authorization NR NR Proxy Require NR NR Prack NR NR Rack NR NR RFC 3262 Reason MAY MAY RFC 3326 Record Route NR NR Refer To NR NR RFC 3515 Referred By NR NR This is a must for some transfers Remote Party ID NR NR Replaces NR NR This is a must for some transfers Reply To NR NR Request Disposition NR NR RFC ietf sip callerprefs 10.txt Requested By NR NR Require MUST MUST Response Key NR NR RFC 3261. Deprecated according to IANA Retry After MAY MAY Route NR NR RSeq MUST MUST RFC 3262 Security Client MAY MAY RFC 3329 Copyright 2008 Microsoft Corporation. All rights reserved. Page 32
Headers SPP GEN SPP REC Comments Security Server MAY MAY RFC 3329 Security Verify MAY MAY RFC 3329 Server SHOULD SHOULD Service Route NR NR RFC 3608 Session Expires SHOULD MAY SIP ETag NR NR RFC ietf sip publish 04.txt SIP If Match NR NR RFC ietf sip publish 04.txt Subject MAY MAY Subscription State MAY MAY RFC 3265 Supported SHOULD SHOULD Timestamp SHOULD SHOULD To MUST MUST Unsupported MAY MAY Used to report an option tag was required buy not supported in a 420 response. User Agent MUST MUST Via MUST MUST Voicemail NR NR Warning SHOULD SHOULD WWW Authenticate MAY MAY 4.3.4 Responses Response SPP GEN SPP REC Comments 1xx Information 100 Trying MUST MUST 180 Ringing MUST MUST 181 Call is being forwarded MAY MAY 182 Queued MAY MAY 183 Session Progress MAY MAY 2xx Successful 200 OK MUST MUST 202 Accepted NR NR RFC 3265 3xx Redirection 300 Multiple choices NR NR 301 Moved permanently NR NR Copyright 2008 Microsoft Corporation. All rights reserved. Page 33
Response SPP GEN SPP REC Comments 302 Moved temporarily NR NR 305 Use proxy NR NR 380 Alternative service NR NR 4xx Request Failure 400 Bad Request MUST MUST 401 Unauthorized SHOULD SHOULD 402 Payment required SHOULD SHOULD 403 Forbidden MUST MUST 404 Not Found MUST MUST 405 Method Not Allowed MUST MUST 406 Not Acceptable MUST MUST 407 Proxy authentication SHOULD required MAY 408 Request timeout MUST MUST 409 Conflict MAY SHOULD 410 Gone MUST MUST 411 Length required NR SHOULD 413 Request entity too MUST large MUST 414 Request URI too long MUST MUST 415 Unsupported media MUST MUST 416 Unsupported URI Scheme MAY MAY 420 Bad extension SHOULD SHOULD 421 Extension Required MAY MAY 422 Session Timer Too Small MAY MAY 423 Interval Too Brief MAY MAY 429 Provide Referrer Identity NR NR RFC ietf sip publish 04.txt 480 Temporarily unavailable MUST MUST 481 Call leg/transaction does not exist MUST MUST 482 Loop detected SHOULD SHOULD 483 Too many hops NR SHOULD 484 Address incomplete MUST MUST 485 Ambiguous MAY SHOULD 486 Busy here MUST MUST 487 Request cancelled MUST MUST 488 Not Acceptable Media MUST SHOULD Copyright 2008 Microsoft Corporation. All rights reserved. Page 34
Response SPP GEN SPP REC Comments 489 Bad Event NR NR RFC 3265 491 Request Pending MAY MAY 493 Undecipherable MAY MAY 494 Security Agreement Required NR NR RFC 3329 5xx Server Failure 500 Server internal error SHOULD SHOULD 501 Not implemented MUST MUST 502 Bad gateway SHOULD SHOULD 503 Service unavailable MUST MUST 504 Gateway timeout SHOULD SHOULD 505 Version not supported SHOULD SHOULD 513 Message Too Large MAY MAY 580 Precondition failed MAY MAY RFC 3312 6xx Global Responses 600 Busy everywhere MAY SHOULD 603 Decline MAY SHOULD 604 Does not exist anywhere MAY SHOULD 606 Not acceptable MAY SHOULD Copyright 2008 Microsoft Corporation. All rights reserved. Page 35