The implementation of SIP trunking in Office Communications Server 2007 R2 supports a constrained set of call scenarios. The diagram below reflects a high-level state machine for a call leg between the Mediation Server and the SIP trunk. From the Idle state, either the service provider or the Mediation Server could send a SIP Invite, which indicates that a call is being offered. Several provisional responses may be sent, such as 180 Ringingindications. However, a final response will ultimately be sent, such as a 480 Temporarily Unavailableor a 200 OK. In the former case, the SIP dialog fails to be established and the call state reverts to Idle. In the latter case, the SIP dialog succeeds and the call state goes to the Active state. During the Active state, the only supported call mediation command is to place the call on and off Hold. This may be done by either endpoint of the SIP dialog by sending another SIP Invitethat contains the appropriate SDP command to indicate the call is active or on hold. From either the Active or On Hold states, the call may be terminated by either endpoint by sending a Bye.

The Mediation Server only supports one method for placing a call on and off hold. To place a call on hold, an additional SIP Invite will be sent on an active call’s SIP dialog. The Session Description Protocol (SDP) body of this dialog contains a full SDP body containing the line a= inactive. To place a call off hold, an additional SIP Invite is sent on a held call’s SIP dialog. The SDP body of this dialog contains a full SDP body containing the line a=sendrecv.

The Mediation Server supports sending and receiving DTMF according to RFC 4733. Effectively, this passes a DTMF tone by sending a stream of real-time transport protocol (RTP) packets on the media channel using a payload type specific to DTMF. This is the same mechanism used in the rest of the Office Communications Server system to pass DTMF digits.

New in Office Communications Server 2007 R2, the Mediation Server now supports the negotiation of Early Media on the Mediation Server per RFC 3960. This enables the negotiation and establishment of a media channel prior to the final 200 OK response. This would enable a service provider to send carrier specific in-band ring tones and ensure that no audio is lost when a user answers the phone. It is optional whether the service provider implements it.

All URI formatting is performed according to RFC 3966, where an E.164 number is preceded by a +. The SIP URI must have a trailing user=phoneparameter. For an example, see the following:

	Copy Code
INVITE sip:+14255550101@s1.ms.com;user=phone From: <sip:+14255550101@g1.contoso.com;user=phone> To: sip:+142575550155@s1.ms.com;user=phone

This coordinates nicely with the Office Communications Server design of passing numbers in E.164 format. Incoming calls are already in the correct format and can be handled by Office Communications Server inbound routing. Outgoing calls, once normalized, can be passed directly to the SIP trunk as an E.164 number without having to perform any number translation.

The Mediation Server only supports G.711a and G.711u at a 20ms packet interval. This would be shown in the SDP as follows:

	Copy Code
a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMU/8000 a=ptime:20

Per RFC 2198, you may have support for sending redundant media packet (also called forward error correction). If it is supported, it is shown in the SDP list as follows:

	Copy Code
a=rtpmap:97 RED/8000

Finally, you may see a final codec for DTMF as follows:

	Copy Code
a=rtpmap:101 telephone-event/8000