SIP Diversion Header Implementation for Redirecting Number
This appendix describes the SIP Diversion Header Implementation for Redirecting Number feature that is introduced in Cisco IOS Release 12.1(5)XM. In addition to the SIP Diversion Header Implementation for Redirecting Number feature, this appendix describes the SIP gateway ability to process a SIP 3xx Redirection response after the receipt of a SIP 18x Information response.
SIP Diversion Header Implementation for Redirecting Number
The SIP Diversion Header Implementation for Redirecting Number feature provides support for a new SIP header field; Call Control (CC)-Diversion. The CC-Diversion header field enables the SIP gateway to pass call control redirecting information during the call setup. Call control redirection is the redirection of a call based on a subscriber service such as call forwarding. Call redirection information is information is typically used for Unified Messaging and voice mail services to identify the recipient of a message. Call control rediversion information can also be used to support applications such as automatic call distribution and enhanced telephony features such as Do Not Disturb and Caller ID.
If generated by the SIP gateway during call process, the CC-Diversion header field is based on the contents of the Redirecting Number Information Element (IE) in the ISDN Setup message. In addition, information such as the reason the call was redirected is included in the CC-Diversion header field.
Figure B-1 illustrates a call flow for this feature.
SIP Gateway 3xx Redirection Response Processing after 18x Information Responses
With Cisco IOS Release 12.1(5)XM, SIP gateways can process SIP 3xx Redirection responses after a 18x Information response has been received.
Processing Redirecting Number IE in ISDN Setup messages
Handling multiple CC-Diversion header fields
Generating multiple CC-Diversion header fields
Gateway-to-Gateway Call—Redirection with CC-Diversion
Figure B-1 illustrates a successful gateway-to-gateway call setup with call redirection with CC-Diversion.
In this scenario, the three end users are identified as Alice at phone A, Bob at phone B, and Carol at phone C. Alice at phone A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. SIP gateway 1 is using a SIP redirect server. Bob at phone B and Carol at phone C are located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. SIP gateway 1 is connected to SIP gateway 2 over an IP network.
The call flow scenario is as follows:
1. Bob at phone B has delegated his calls to Carol at phone C.
1. Alice at phone A initiates a call with Bob via SIP gateway 1that is using a SIP proxy server.
2. The proxy server returns Carol at SIP gateway 2 as a contact location for Bob.
3. Gateway 1 initiates call with Carol.
4. Carol answers the call.
Figure B-1 SIP Gateway-to-SIP Gateway—Call Redirection with CC-Diversion
Step
Action
Description
1
Setup—PBX A to SIP gateway 1
Call Setup is initiated between PBX A and SIP gateway 1.
2
Call Proceeding—SIP gateway 1 to PBX A
SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
3
INVITE—SIP gateway 1 to SIP proxy server
GW1 sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session.
In the INVITE request:
Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address 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 Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name.
Alice via GW1 is identified as the call session initiator in the From field.
A unique numeric identifier is assigned to the call and inserted in the Call-ID field.
The transaction number within a single call leg is identified in the CSeq field.
The media capability GW1 is ready to is specified in the SDP.
The port on which GW1 is prepared to receive the RTP data is specified in the SDP.
Alice at GW1 is specified as a CC-Diversion header. In addition, the CC-Diversion header field contains a reason for the diversion and a counter. Possible values for the diversion reason include the following: unknown, user-busy, no-answer, unconditional, deflection, and follow-me.
4
302 Moved Temporarily—SIP proxy server to SIP gateway 1
The SIP proxy server determines that Bob's calls have been configured to be redirected to Carol at phone C via GW2. The SIP proxy server sends an 302 Moved Temporarily message to GW1.
In the 302 Moved Temporarily message, Carol at GW2 is added as the Contact and there are two CC-Diversion header fields included; one for Alice at GW1 (IP address or domain name) and one for Bob at GW2 (IP address or domain name).
5
ACK—SIP gateway 1 to SIP proxy server
An ACK message is sent from GW1 to the SIP proxy server.
6
INVITE—SIP gateway 1 to SIP gateway 2
SIP gateway 1 sends an INVITE request to Carol at phone C via GW2. The INVITE request contains two CC-Diversion headers; one for Alice at GW1 (IP address or domain name) and one for Bob at GW2 (IP address or domain name).
7
Setup—SIP gateway 2 to PBX B
SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with Carol via PBX B. In the Call Setup, the ISDN Redirecting Number IE is generated using the contents of the top CC-Diversion header field; in this case, Bob at GW2.
8
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.
9
Alerting—PBX B to SIP gateway 2
PBX B locates Carol at phone C and sends an Alert message to SIP gateway 2. Carol's phone begins to ring.
10
180 Ringing—SIP gateway 2 to SIP gateway 1
SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, Carol at phone C.
11
Alerting—SIP gateway 1 to PBX A
SIP gateway 1 sends an Alert message to PBX A. Alice hears ringback tone.
At this point, a one-way voice path is established between SIP gateway 1 and PBXA and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
12
Connect—PBX B to SIP gateway 2
Carol answers phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
13
200 OK—SIP gateway 2 to SIP gateway 1
SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
If Carol via SIP gateway 2 supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and Alice's media capability in the 200 OK response. If Carol at SIP gateway 2 does not support the media capability advertised by Alice at SIP gateway 1, SIP gateway 2 sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
14
Connect—SIP gateway 1 to PBX A
SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
15
Connect ACK—PBX A to SIP gateway 1
PBX A acknowledges SIP gateway 1's Connect message.
16
ACK—SIP gateway 1 to SIP gateway 2
SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 200 OK response has been received.
The call is now in progress over a two-way voice path via RTP.
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.
Gateway-to-Gateway Call—SIP 3xx Redirection Response After Receipt of a SIP 18x Information Response
Figure B-2 illustrates a successful gateway-to-gateway call setup in which a SIP 3xx Redirection response is processed after the receipt of a SIP 18x Information response.
In this scenario, the three end users are identified as Alice at phone A, Bob at phone B, and Carol at phone C. Alice at phone A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. SIP gateway 1 is using a SIP redirect server. Bob at phone B and Carol at phone C are located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. SIP gateway 1 is connected to SIP gateway 2 over an IP network.
The call flow scenario is as follows:
1. Bob at phone B has delegated his calls to Carol at phone C.
1. Alice at phone A initiates a call with Bob via SIP gateway 1that is using a SIP proxy server.
2. The proxy server returns Carol at SIP gateway 2 as a contact location for Bob.
3. Gateway 1 initiates call with Carol.
4. Carol answers the call.
Figure B-2 Gateway-to-Gateway Call—Call Redirection after Receipt of a SIP 18x Response
Step
Action
Description
1
Setup—PBX A to SIP gateway 1
Call Setup is initiated between PBX A and SIP gateway 1.
2
Call Proceeding—SIP gateway 1 to PBX A
SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
3
INVITE—SIP gateway 1 to SIP proxy server
GW1 sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session.
In the INVITE request:
Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address 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 Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name.
Alice via GW1 is identified as the call session initiator in the From field.
A unique numeric identifier is assigned to the call and inserted in the Call-ID field.
The transaction number within a single call leg is identified in the CSeq field.
The media capability GW1 is ready to is specified in the SDP.
The port on which GW1 is prepared to receive the RTP data is specified in the SDP.
Alice at GW1 is specified as a CC-Diversion header. In addition, the CC-Diversion header field contains a reason for the diversion and a counter. Possible values for the diversion reason include the following: unknown, user-busy, no-answer, unconditional, deflection, and follow-me.
4
100 Trying—SIP proxy server to SIP gateway 1
The SIP proxy server sends a 100 Trying to GW1.
5
183 Session Progress—SIP proxy server to SIP gateway 1
The SIP proxy server sends a 180/183 Session Progress response to SIP gateway 1 (GW1).
Timer expires message—SIP proxy server to SIP gateway 1
No-answer timer expires on the proxy server. Proxy server sends a 302 to GW1.
ACK—SIP gateway 1 to SIP proxy server
GW1 sends an ACK to the proxy server for the 302.
8
302 Moved Temporarily—SIP proxy server to SIP gateway 1
The SIP proxy server determines that Bob's calls have been configured to be redirected to Carol at phone C via GW2. The SIP proxy server sends an 302 Moved Temporarily message to GW1.
In the 302 Moved Temporarily message, Carol at GW2 is added as the Contact and there are two CC-Diversion header fields included; one for Alice at GW1 (IP address or domain name) and Bob at GW2 (IP address or domain name).
9
INVITE—SIP gateway 1 to SIP gateway 2
SIP gateway 1 sends an INVITE request to Carol at phone C via GW2. The INVITE request contains two CC-Diversion headers; one for Alice at GW1 (IP address or domain name) and Bob at GW2 (IP address or domain name).
10
Setup—SIP gateway 2 to PBX B
SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with Carol via PBX B. In the Call Setup.
11
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.
12
Alerting—PBX B to SIP gateway 2
PBX B locates Carol at phone C and sends an Alert message to SIP gateway 2. Carol's phone begins to ring.
13
180 Ringing—SIP gateway 2 to SIP gateway 1
SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, Carol at phone C.
14
Alerting—SIP gateway 1 to PBX A
SIP gateway 1 sends an Alert message to PBX A. Alice hears ringback tone.
At this point, a one-way voice path is established between SIP gateway 1 and PBXA and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
15
Connect—PBX B to SIP gateway 2
Carol answers phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
16
200 OK—SIP gateway 2 to SIP gateway 1
SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
If Carol via SIP gateway 2 supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and Alice's media capability in the 200 OK response. If Carol at SIP gateway 2 does not support the media capability advertised by Alice at SIP gateway 1, SIP gateway 2 sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
17
Connect—SIP gateway 1 to PBX A
SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
18
Connect ACK—PBX A to SIP gateway 1
PBX A acknowledges SIP gateway 1's Connect message.
19
ACK—SIP gateway 1 to SIP gateway 2
SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 200 OK response has been received.
The call is now in progress over a two-way voice path via RTP.
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.
