SIP Gateway Support for Third Party Call Control

This appendix describes the SIP Gateway Support for Third-Party Call Control feature that is introduced in Cisco IOS Release 12.1(5)XM. In addition to the SIP Gateway Support for Third-Party Call Control feature, this appendix describes the SIP gateway's ability to process Fully Qualified Domain Names (FQDNs) in the SIP media.

Third-party Call Control via Delayed Media

The SIP gateway support for third-party call control enables one endpoint (for example, a call controller) to create, modify, or terminate calls between other endpoints via delayed media negotiation. A delayed media negotiation is one where the Session Description Protocol (SDP) information is not completely advertised in the initial call setup.

When delayed media negotiation takes place between two SIP endpoints (User A and User B) and a controlling endpoint (call controller) that is creating the call between User A and User B, the following actions take place:

1. The call controller sends an INVITE request to the first endpoint to be included in the call (User A). The INVITE does not contain an SDP body.

2. The call controller sends an INVITE request to the second endpoint to be included in the call (User B). The INVITE request does not contain an SDP body.

3. User A sends a 200 OK response to the call controller. The 200 OK response contains User A's SDP information.

4. User B sends a 200 OK response to the call controller. The 200 OK response contains User B's SDP information.

5. On receiving a 200 OK response from User A, the call controller sends an ACK response to User A. The ACK response contains User B's SDP information.

6. On receiving a 200 OK response from User B, the call controller sends an ACK response to User B that contains User A's SDP information.

Third-party call control is often used for operator services (creating a call connecting two parties together) and conferencing.

The following call flows illustrate the use of third-party call control via Delayed Media support:

Endpoints Specified as FQDNs in the SDP

With Cisco IOS Release 121(5)XM, SIP gateways can route on an FQDN in addition to routing on an IP address. When the SIP gateway receives a SIP message containing a FQDN in the c= SDP field, it parses the c= field of the SDP body, determines that it is a FQDN and resolves the next hop via a DNS query.

Figure A-4 illustrates a call flow of this feature.

SIP Gateway-to-SIP Gateway Call—Call Setup with Delayed Media via Third-Party Call Controller

Figure A-1 illustrates a successful gateway-to-gateway call setup via a third-party call control agent.

The call flow scenario is as follows:

1. The call controller calls User B and then calls User A.

2. User A answers the call.

3. User B answers the call.

4. The call controller connects User A and User B.

Figure A-1: SIP Gateway-to-SIP Gateway—Call Setup via Third-Party Call Controller

Step	Action	Description
1	INVITE—Call controller to SIP gateway 2	The third party call control agent sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session. In the INVITE request: The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The SDP media line is omitted or the INVITE does not contain any SDP information.
2	INVITE—Call controller to SIP gateway 1	The third party call control agent sends an INVITE request to SIP gateway 1. The INVITE request is an invitation to User A to participate in a call session. In the INVITE request: The phone number of User A is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User A and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User A appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The SDP media line is omitted or the INVITE does not contain any SDP information.
3	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from the call controller and initiates a Call Setup with User B via PBX B.
4	Setup—SIP gateway 1 to PBX A	SIP gateway 1 receives the INVITE request from the call controller and initiates a Call Setup with User A via PBX A.
5	100 Trying—SIP gateway 2 to call controller	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by the call controller. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
6	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
7	100 Trying—SIP gateway 1 to call controller	SIP gateway 1 sends a 100 Trying response to the INVITE request sent by the call controller. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User A has not yet been located and that some unspecified action, such as a database consultation, is taking place.
8	Call Proceeding—PBX A to SIP gateway 1	PBX A sends a Call Proceeding message to SIP gateway 1 to acknowledge the Call Setup request.
9	183 Session Progress—SIP gateway 2 to call controller	SIP gateway 2 sends a 183 Session Progress message to the call controller.
10	183 Session Progress—SIP gateway 1 to call controller	SIP gateway 1 sends a 183 Session Progress message to the call controller.
11	Connect—PBX A to SIP gateway 1	User A answers phone. PBX A sends a Connect message to SIP gateway 1. The Connect message notifies SIP gateway 1 that the connection has been made.
12	200 OK—SIP gateway 1 to call controller	SIP gateway 1 sends a 200 OK response to the call controller. The 200 OK response notifies the call controller that the connection has been made. In the call 200 OK response, the SDP information of User A is specified.
13	Connect ACK—SIP gateway 1 to PBX A	SIP gateway 1 acknowledges PBX A's Connect message.
14	Connect—PBX B to SIP gateway 2	PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
15	200 OK—SIP gateway 2 to call controller	SIP gateway 2 sends a 200 OK response to the call controller. The 200 OK response notifies the call controller that the connection has been made. In the call 200 OK response, the SDP information of User B is specified.
16	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message.
17	ACK—Call controller to SIP gateway 1	The call controller sends an ACK response to SIP gateway 1. The ACK response confirms that the call controller has received the 200 OK response from SIP gateway 1. In the ACK response, the SDP information of User B is specified. Media negotiation takes place.
14	ACK—Call controller to SIP gateway 2	The call controller sends an ACK response to SIP gateway 2. The ACK response confirms that the call controller has received the 200 OK response from SIP gateway 2. In the ACK response, the SDP information of User A is specified. Media negotiation takes place.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.

SIP IP Phone-to-SIP Gateway—Call Setup and Call Hold with Delayed Media

Figure A-2 illustrates a successful SIP IP phone-to-SIP gateway call setup and call hold using delayed media.

The call flow scenario is as follows:

1. User A calls User B.

2. User A puts User B on hold.

3. User A takes User B off hold.

Figure A-2: SIP IP Phone-to-SIP Gateway—Call Setup and Call Hold with Delayed Media

Step	Action	Description
1	INVITE—SIP IP phone to SIP gateway	SIP IP phone sends an INVITE request to the SIP gateway. The INVITE request is an invitation to User B to participate in a call session. In the INVITE request: The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. SIP IP phone is identified as the call session initiator in the From field. A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability User A is ready to receive is specified.
2	Setup B—SIP gateway to PBX	The SIP gateway receives the INVITE request from the call controller and initiates a Call Setup with User B via the PBX.
3	Call Proceeding—PBX to SIP gateway	The PBX sends a Call Proceeding message to the SIP gateway to acknowledge the Call Setup request.
4	Alerting—PBX to SIP gateway	The PBX sends an Alert message to the SIP gateway.
5	180 Ringing—SIP gateway to SIP IP phone	The SIP gateway sends a 180 Ringing response to the SIP IP phone. The 180 Ringing response indicates that the User B is being alerted.
6	Connect—PBX to SIP gateway	User B answers the phone. The PBX sends a Connect message to the SIP gateway. The Connect message notifies the SIP gateway that the connection has been made.
7	200 OK—SIP gateway to SIP IP phone	The SIP gateway sends a 200 OK response to the SIP IP phone. The 200 OK response notifies the SIP IP phone that the connection has been made.
8	ACK—SIP IP phone to SIP gateway	SIP IP phone sends an ACK to the SIP gateway. The ACK confirms that the SIP IP phone has received the 200 OK response from the SIP gateway.
9	Connect ACK—SIP gateway to PBX	The SIP gateway acknowledges the PBX's Connect message. The call between User A and User B session is now active.
A two-way RTP channel is established between the SIP IP phone and the SIP gateway. A two-way voice path is established between the SIP gateway and the PBX.
10	INVITE—SIP IP phone to SIP gateway	SIP IP phone (User A) sends a mid-call INVITE request to the SIP gateway with a modified SDP session connection parameter (c=) that places the existing call between User A and User B on hold. The c= SDP field of the SIP INVITE contains an 0.0.0.0. This places the call in limbo.
11	200 OK—SIP gateway to SIP IP phone	SIP gateway 1 sends a 200 OK response to the SIP IP phone. The 200 OK response notifies the SIP IP phone that the INVITE was successfully processed.
12	ACK—SIP IP phone to SIP gateway	The SIP IP phone sends an ACK to the SIP gateway. The ACK confirms that the SIP IP phone has received the 200 OK response. The call session is now temporarily inactive. No RTP packets are being sent.
13	INVITE—SIP IP phone to SIP gateway	SIP IP phone sends an INVITE with delayed media to the SIP gateway. No media is specified in the SDP media name and transport address (m=) parameter.
14	200 OK—SIP gateway to SIP IP phone	The SIP gateway sends a 200 OK response to User A. In the 200 OK response, the SDP information of User B is specified.
15	ACK—SIP IP phone to SIP gateway	SIP IP phone sends an ACK to the SIP gateway. The ACK confirms that the SIP IP phone has received the 200 OK response from the SIP gateway. In the ACK response, the SDP information of User A is specified. Media negotiation takes place.
A two-way RTP channel is reestablished between the SIP IP phone and the SIP gateway. A two-way voice path (to User B) is established between the SIP gateway and the PBX.

SIP Gateway-to-uOne Call—Call Setup with Voice Mail

Figure A-3 illustrates a successful SIP gateway-to-uOne system call setup.

Figure A-3: SIP Gateway-to-SIP Gateway—Call Setup and Voice Mail

Step	Action	Description
1	INVITE—SIP gateway 1 to application server	SIP gateway 1 sends an INVITE request to the application server.
2	INVITE—Application server to SIP gateway 2	The application server sends the INVITE request to SIP gateway 2.
3	183 Session Progress—SIP gateway 2 to application server	SIP gateway 2 sends a 183 Session Progress message to the application server.
4	183 Session Progress—Application server to SIP gateway 1	The application server proxies the 183 Session Progress message to SIP gateway 1.
At this time a timeout occurs.
5	Voice Mail control messages—Application server to uOne server	The application server forwards voice mail control messages to the uOne server (media server).
6	200 OK—uOne server to application server	The uOne server sends a 200 OK response to the application server. In the 200 OK response, the uOne server SDP is included.
7	200 OK response—Application server to SIP gateway 1	The application server proxies the 200 OK response to the SIP gateway. In the 200 OK response, the uOne server SDP is included.

SIP Gateway-to-SIP Gateway—Call Setup using a FQDN and Delayed Media

Figure A-4 illustrates a successful gateway-to-gateway call setup using delayed media and a FQDN in the SDP session connection parameter.

Figure A-4: SIP Gateway-to-SIP Gateway—Call Setup using an FQDN in SDP

Step	Action	Description
1	INVITE—Call controller to SIP gateway 2	The third party call control agent sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session. In the INVITE request: The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The SDP media line is omitted or the INVITE does not contain any SDP information.
2	INVITE—Call controller to SIP gateway 1	The third party call control agent sends an INVITE request to SIP gateway 1. The INVITE request is an invitation to User A to participate in a call session. In the INVITE request: The phone number of User A is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User A and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User A appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The SDP media line is omitted or the INVITE does not contain any SDP information.
3	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from the call controller and initiates a Call Setup with User B via PBX B.
4	Setup—SIP gateway 1 to PBX A	SIP gateway 1 receives the INVITE request from the call controller and initiates a Call Setup with User A via PBX A.
5	100 Trying—SIP gateway 2 to call controller	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by the call controller. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
6	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
7	100 Trying—SIP gateway 1 to call controller	SIP gateway 1 sends a 100 Trying response to the INVITE request sent by the call controller. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User A has not yet been located and that some unspecified action, such as a database consultation, is taking place.
8	Call Proceeding—PBX A to SIP gateway 1	PBX A sends a Call Proceeding message to SIP gateway 1 to acknowledge the Call Setup request.
9	183 Session Progress—SIP gateway 2 to call controller	SIP gateway 2 sends a 183 Session Progress message to the call controller.
10	183 Session Progress—SIP gateway 1 to call controller	SIP gateway 1 sends a 183 Session Progress message to the call controller.
11	Connect—PBX A to SIP gateway 1	User A answers phone. PBX A sends a Connect message to SIP gateway 1. The Connect message notifies SIP gateway 1 that the connection has been made.
12	200 OK—SIP gateway 1 to call controller	SIP gateway 1 sends a 200 OK response to the call controller. The 200 OK response notifies the call controller that the connection has been made. In the call 200 OK response, the SDP information of User A is specified.
13	Connect ACK—SIP gateway 1 to PBX A	SIP gateway 1 acknowledges PBX A's Connect message.
14	Connect—PBX B to SIP gateway 2	PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
15	200 OK—SIP gateway 2 to call controller	SIP gateway 2 sends a 200 OK response to the call controller. The 200 OK response notifies the call controller that the connection has been made. In the call 200 OK response, the SDP information of User B is specified.
16	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message.
17	ACK—Call controller to SIP gateway 1	The call controller sends an ACK response to SIP gateway 1. The ACK response confirms that the call controller has received the 200 OK response from SIP gateway 1. In the ACK response the media capability of User B is specified and the domain name of gateway 2 is specified in the SDP sessions parameter (c=) field. Media negotiation takes place. At this time, a DNS query is performed by SIP gateway 1 to resolve c=IN IP4 gw2.com.
18	ACK—Call controller to SIP gateway 2	The call controller sends a an ACK to SIP gateway 2. The ACK confirms that the call controller has received the ACK response from SIP gateway 2. In the 200 OK response the media capability of User A is specified and the domain name of gateway 1 is specified in the SDP sessions parameter (c=). Media negotiation takes place. At this time, a DNS query is performed by SIP gateway 2 to resolve c=IN IP4 gw1.com.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.