How to insert the router DNS name in the SIP URI and in the SIP from Header

Resolution

This feature is implemented in Cisco IOS Software Release 12.4(2) onwards. Once Cisco IOS is upgraded to anything later than 12.4(2)T, you can do this configuration:

#configure terminal
(config)#voice service voip
(conf-voip-serv)#sip
(conf-serv-sip)#[no | default] localhost dns:

Example:
(conf-serv-sip)#localhost dns:name1.com

In order to disable the usage of DNS name under specific dial-peers, you can configure the dial-peer with:


#configure terminal
(config) dial-peer voice 100 voip
(config-dial-peer)#[no | default] voice-class sip localhost
[dns]:

In the CLI, there is a provision to exclude a specific dialpeer from the use of the global configuration under voice service voip. In order to do that, use the no version command under dialpeer. This change has been made to allow for the case when the global localhost command is configured and most but not all the dialpeers want to use that config. For the dialpeers that want to fallback to the use of the IP address in the From, Call-ID & RPID headers, this command can be useful.The default version of the command causes the dial-peer to use the globally configured CLI under voice service voip, SIP.

Example:
dial-peer voice 6 voip
no voice-class sip localhost

SRST Support for SIP phones

You can use SIP SRST for SIP  IP phones.

Cisco Unified SIP SRST provides backup to an external SIP proxy server by  providing basic registrar and redirect server or back-to-back user agent (B2BUA)  services. These services are used by a SIP IP phone in the event of a WAN  connection outage when the SIP phone is unable to communicate with its primary  SIP proxy.

Cisco Unified SIP SRST can support SIP phones with standard  RFC 3261 feature support locally and across SIP WAN networks. With Cisco Unified  SIP SRST, SIP phones can place calls across SIP networks in the same way as SCCP  phones.

Cisco Unified SIP SRST supports the following call combinations:

• SIP phone to SIP phone
• SIP phone to PSTN / router voice-port
• SIP phone to Skinny Client Control Protocol (SCCP) phone
• SIP phone to WAN VoIP using SIP

For more information, refer the following documents:

• Cisco Unified SIP SRST System Administrator Guide
• Cisco Unified SRST 7.1 New  Features

SIP Trunk between CUCM 7.X to Service Provider 2011

Introduction

This document covers the Network Design and Configuration of SIP Trunk deployement between the Cisco Unified Communications Manager (CUCM) and Service Provider Soft Switch.
This model of SIP Trunk Interconnection is widely used by large enterprises with branch office connecting to SIP Service Provider for routing Long distance Calls. It covers the Network topology with Components used and the Configuration screenshots.

Components Used

• Cisco Unified Communications Manager 7.1(3)
• Cisco Unified Border Element (Cisco UBE)
• 7962 IP Phones

Configuration in this document are tested on specific lab environment using CUCM 7.1(3). The Procedures remains the same for CUCM 7.x and 8.x. Hence this document will be applicable for both CUCM 7.x and CUCM 8.x

Network Topology

Cisco Unified Communications Manager CUCM is located at the Headquarters with IP Phones Interconnected and Cisco UBE with SRST feature is located at the Branch office Interconnecting the IP Phones in the Branch location.

Case Study

SIP Trunk has to be established between the CUCM 172.16.101.210 at Headquarters, Cisco Unified SRST and the SIP Service Provider Soft Switch 10.6.33.32.
Long Distance Calls with Route Pattern 98400 has to be routed from the CUCM IP Phones at the Headquarters and Branch towards the SIP Service Provider thru the Cisco UBE in the respective locations.

CUCM: 172.16.101.210
Cisco UBE at Headquarters: 10.30.97.5
Cisco UBE at Branch: 10.40.95.2
SIP SP Softswitch: 10.6.33.32

Configuring Cisco Unified Communications Manage

1. Configuring the System Parameters : Server

Go to Cisco Unified CM > System > Server and Configure the following

· Host Name / IP address : 172.16.101.210

· Description : CUCM - HDQ

2. Configuring the System Parameters : Region

Go to Cisco Unified CM > System > Region and Configure the following

· Name : Region-HQ-IPPhone

· Audio codec : G.729

· Video call Bandwdth

Similarly Create the Region, "Region –Branch-IPPhone" and "Region WAN"

3. Configuring the System Parameters : Device

Go to Cisco Unified CM > System > Device and Configure the following

· Device Pool Name : DevicePool _Region_HDQ

· Region : Region-HQ-IPPhone

· Video call Bandwdth

Similarly Create the Device Pool, "DevicePool_Branch" and "DevicePool_WAN"

4. Configuring the System Parameters : Location

Go to Cisco Unified CM > System > Location and Configure the following

· Name : HUB_HDQ

· Audio Bandwidth

· Video Bandwidth

Similarly Create the Location "HUB_REGION"

5. Configuring the System Parameters : SRST

Go to Cisco Unified CM > System > SRST and Configure the following

· Name : SRST-to-BRANCH1

· Port : 2000

· IP address : 172.16.103.210 (Branch CUBE IP address with SRST enabled)

· SIP Port : 5060

6. Configuring the Call Routing Parameters : Class of control

Go to Cisco Unified CM > Call Routing > Class of control and Configure the following

· Name : Partition_HDQ_IPPhones

· Description : Partition_HDQ_IPPhones

Similarly Create the Partitions, "Partition_Region_IPPhones"

7. Configuring the Call Routing Parameters : Calling Search Space

Go to Cisco Unified CM > Call Routing > Calling search space and Configure the following

· Name : CSS_HDQ_IPPhone

· Description : CSS_HDQ_IPPhone

· Select the Partitions to Route Partitions for the Calling search space

Similarly Create the Calling search space, "CSS_Branch_IPPhone".

8. Configuring the Device Parameters : Gateway

Go to Cisco Unified CM > Device> Gateway and Configure the following

· Product : Cisco 3845

· Gateway : 3845BR

· Protocol : MGCP

· Domain Name : 3845BR

· Description : Branch1 GW ( located at the Branch office )

9. SIP Trunk Creation from CUCM to Service Provider

9.1. Configuring the Device Parameters : Trunk

Go to Cisco Unified CM > Device> Trunk and Configure the following

· Product : SIP Trunk

· Device Protocol : SIP

· Device Name : GW-SIP-HQ

· Device Pool : DevicePool_Region_HDQ

· Class classification : Use system default

· Location : HUB_HDQ

· Under the section Inbound calls : Calling Search Space – CSS_HDQ_IPPhone

SIP Trunk Creation from CUCM to Gateway at Headquarters IP : 10.30.97.5 and then Call Routed to Service Provider IP : 10.6.33.32

SIP Trunk Creation from CUCM to Gateway at Branch IP : 10.40.95.2 and then Call Routed to Service Provider IP : 10.6.33.32

· Product : SIP Trunk

· Device Protocol : SIP

· Device Name : GW-SIP-BR

· Device Pool : DevicePool_Branch

· Class classification : Use system default

· Location : HUB_REGION

· Under the section Inbound calls : Calling Search Space – CSS_Branch_IPPhone

10. Configuring the Route Pattern for Routing the Calls Towards the SIP Service Provider

10.1. Configuring the Call Routing Parameters : Route/Hunt

Go to Cisco Unified CM > Call Routing > Route/Hunt and Configure the following

Creating Route Pattern for long distance calling from Headquarters

· Route Pattern : 98400xxxxx

· Route Partition : Partition_HDQ_IPPhones

· Description : Longdistance call to SIP SP

· Gateway/Routelist : GW-SIP-HQ( GW: 10.30.97.5, Refer Section 9 : Configuring the Device Parameter :Trunk )

Creating Route Pattern for long distance calling from Branch

· Route Pattern : 98400xxxxx

· Route Partition : Partition_Region_IPPhones

· Description : Longdistance call to SP

· Gateway/Routelist : GW-SIP-BR( GW: 10.40.95.2, Refer Section 9 : Configuring the Device Parameter :Trunk )

11. Configuring the Device Parameters : Phone

Go to Cisco Unified CM > Device> Phone and Configure the following

Create IP Phones in the Headquarters

· MAC Address

· Directory Number : 4155000

· Device Pool : DevicePool_Region_HDQ

· Calling search space : CSS_HDQ_IPPhone

Create IP Phones in the Branch

· MAC Address

· Directory Number : 4156000

· Device Pool : DevicePool_Branch

· Calling search space : CSS_Branch_IPPhone

Configuring the Cisco Unified Border Elements

Configure the Dial-peer for Routing Long distance Outgoing Call from CUCM To SIP Service Provider

CUCM IP : 172.16.101.210
SIP Service Provider IP : 10.6.33.32

Sample Dial-Peer Configuration for Routing Calls to SIP S

Sample CUBE-HQ Configuration
CUBEHQ # Voice service voip allow-connections sip to sip ! dial-peer voice 3000 voip description Incoming Dial-Peer codec g729r8 session protocol sipv2 incoming called-number 4155T dtmf-relay rtp-nte digit-drop no vad dial-peer voice 3001 voip description Outgoing Dial-Peer-CUCM destination-pattern 4155T codec g729r8 max-redirects 5 session protocol sipv2 session target ipv4:172.16.101.210 dtmf-relay rtp-nte digit-drop no vad dial-peer voice 3003 voip description Incoming Dial-Peer codec g729r8 session protocol sipv2 incoming called-number .T dtmf-relay rtp-nte digit-drop no vad ********* Routing 98400xxxxx towards SIP Service Provider IP : 10.6.33.32 *********** dial-peer voice 4000 voip description Outgoing Dial-Peer to SIP SP destination-pattern 98400xxxxx codec g729r8 voice-class sip early-offer forced max-redirects 5 session protocol sipv2 session target ipv4:10.6.33.32 dtmf-relay rtp-nte digit-drop no vad
Note:- This section covers only the Dial-Peer Configuration for routing calls towards the SIP Service Provider

Sample Dial-Peer Configuration of CUBE located at Branch office

Sample CUBE-Branch Configuration
BRGW # voice service voip address-hiding allow-connections sip to sip ! mgcp mgcp call-agent 172.16.101.210 2427 service-type mgcp version 0.1 mgcp dtmf-relay voip codec all mode out-of-band mgcp sdp simple mgcp fax t38 inhibit mgcp bind control source-interface GigabitEthernet0/1.1 mgcp bind media source-interface GigabitEthernet0/1.1 ********* Routing 98400xxxxx towards SIP Service Provider IP : 10.6.33.32 *********** dial-peer voice 2000 voip description Outgoing Dial-Peer to SIP SP destination-pattern 98400xxxxx codec g729r8 voice-class sip early-offer forced max-redirects 5 session protocol sipv2 session target ipv4:10.6.33.32 dtmf-relay rtp-nte digit-drop no vad dial-peer voice 5000 voip description Incoming Dial-Peer codec g729r8 session protocol sipv2 incoming called-number 4156T dtmf-relay rtp-nte digit-drop no vad dial-peer voice 5001 voip description Outgoing Dial-Peer-CUCM destination-pattern 4156T codec g729r8 max-redirects 5 session protocol sipv2 session target ipv4:172.16.101.210 dtmf-relay rtp-nte digit-drop no vad dial-peer voice 5000 voip description Incoming Dial-Peer codec g729r8 session protocol sipv2 incoming called-number .T dtmf-relay rtp-nte digit-drop no vad
Note:- This section covers only the Dial-Peer Configuration for routing calls towards the SIP Service Provider

Troubleshooting the replication issues

Troubleshooting the replication issues

To see the CLI commands, type:

admin:   utils dbreplication  ?

Most commonly used 4 commands are:

                 utils dbreplication status 

       (checks each table on all servers, sees if tables out of synch)

                 utils dbreplication repair

       (use to sync tables, run it on the pub. Can be run for a sub, or all.

       “utils dbreplication repair <nodename>” will sync one sub.

       “utils dbreplication repair all” will sync all.)

                 utils dbreplication stop

       (use this command on sub and pub before a “utils dbreplication reset” .

         Run the “stop” locally on sub, then pub. If you are going  to reset all, run stop on each sub, then    on the pub)

                 utils dbreplication reset

        (use to restart replication on one sub or all nodes.

        Use “utils dbreplication reset <nodename>” to reset replication on one sub.

        Use “utils dbreplication reset all” to reset replication on pub and all subs.)

Configuring SIP Phones for Making Basic Calls

Configuring SIP Phones for Making Basic Calls

The following is a configuration example for SIP phones running on Cisco Unified CME:

voice service voip

 allow-connections sip to sip

 sip

 registrar server expires max 600 min 60

!

voice class codec 1

 codec preference 1 g711ulaw

!

voice hunt-group 1 parallel

 final 8000

 list 2000,1000,2101

 timeout 20

 pilot 9000

!

voice hunt-group 2 sequential

 final 1000

 list 2000,2300

 timeout 25

 pilot 9100 secondary 9200

!

voice hunt-group 3 peer

 final 2300

 list 2100,2200,2101,2201

 timeout 15

 hops 3

 pilot 9300

 preference 5

!

voice hunt-group 4 longest-idle

 final 2000

 list 2300,2100,2201,2101,2200

 timeout 15

 hops 5

 pilot 9400 secondary 9444

 preference 5 secondary 9

!

voice register global

 mode cme

!

 external-ring bellcore-dr3

!

voice register dn 1

 number 2300

 mwi

!

voice register dn 2

 number 2200

 call-forward b2bua all 1000

 call-forward b2bua mailbox 2200

 mwi

!

voice register dn 3

 number 2201

 after-hour exempt

!

voice register dn 4

 number 2100

 call-forward b2bua busy 2000

 mwi

 

voice register dn 5

 number 2101

 mwi

 

voice register dn 76

 number 2525

 call-forward b2bua unreachable 2300

 mwi

!

voice register template 1

!

voice register template 2

 no conference enable

 voicemail 7788 timeout 5

!

voice register pool 1

 id mac 000D.ED22.EDFE

 type 7960

 number 1 dn 1

 template 1

 preference 1

 no call-waiting

 codec g711alaw

!

voice register pool 2

 id mac 000D.ED23.CBA0

 type 7960

 number 1 dn 2

 number 2 dn 2

 template 1

 preference 1

!

 dtmf-relay rtp-nte

 speed-dial 3 2001

 speed-dial 4 2201

!

voice register pool 3

 id mac 0030.94C3.053E

 type 7960

 number 1 dn 3

 number 3 dn 3

 template 2

!

voice register pool 5

 id mac 0012.019B.3FD8

 type ATA

 number 1 dn 5

 preference 1

 dtmf-relay rtp-nte

 codec g711alaw

!

voice register pool 6

 id mac 0012.019B.3E88

 type ATA

 number 1 dn 6

 number 2 dn 7

 template 2

 dtmf-relay-rtp-nte

 call-forward b2bua all 7778

!

voice register pool 7

!

voice register pool 8

 id mac 0006.D737.CC42

 type 7940

 number 1 dn 8

 template 2

 preference 1

 codec g711alaw

!

voice-port 1/0/0

!

voice-port 1/0/1

!

dial-peer voice 100 pots

 destination-pattern 2000

 port 1/0/0

!

dial-peer voice 101 pots

 destination-pattern 2010

 port 1/0/1

!

dial-peer voice 1001 voip

 preference 1

 destination-pattern 1...

 session protocol sipv2

 session target ipv4:10.15.6.13

 codec g711ulaw

!

sip-ua

 mwi-server ipv4:1.15.6.200 expires 3600 port 5060 transport udp

!

telephony-service

 load 7960-7940 P0S3-07-2-00

 max-ephones 24

 max-dn 96

 ip source-address 10.15.6.112 port 2000

 create cnf-files version-stamp Aug 24 2004 00:00:00

 max-conferences 8

 after-hours block pattern 1 1...

 after-hours day Mon 17:00 07:00

Disabling a Bulk Registration for a SIP Phone:

The following example shows that all phone numbers that match the pattern "408555.." can register with the SIP proxy server (IP address 1.5.49.240) except directory number 1, number "4085550101," for which bulk registration is disabled:

voice register global

 mode cme

 bulk 408555....

!

voice register dn 1

 number 4085550101

 no-reg

sip-ua

 registrar ipv4:1.5.49.240

Call Flow Examples

Call Flow Examples

1. Call Flow between PBX to Cisco SIP IP Phone—Successful Setup and Disconnect

Below diagram illustrates a successful gateway-to-Cisco SIP IP phone call setup and disconnect. In this scenario, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to Gateway 1 (SIP Gateway) via a T1/E1. User B is located at a Cisco SIP IP phone. Gateway 1 is connected to the Cisco SIP IP phone over an IP network.
The call flow is as follows:
1. User A calls User B.
2. User B answers the call.
3. User B disconnects the call.

Step	Action	Description
1.	Setup—PBX A to Gateway 1	Call Setup is initiated between PBX A   and Gateway 1. The Call Setup includes the standard transactions that take   place as User A attempts to call User B.
2.	INVITE—Gateway 1 to Cisco SIP IP   phone	Gateway 1 maps the SIP URL phone   number to a dial peer. The dial peer includes the IP address and the port   number of the SIP-enabled entity to contact. Gateway 1 sends a SIP   INVITE request to the address it receives as the dial peer, which, in this   scenario, is the Cisco SIP IP phone. In the INVITE request: The        IP address of the Cisco SIP IP phone is inserted in the Request-URI        field. PBX        A 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. The        port on which the Gateway is prepared to receive the RTP data is        specified.
3.	Call Proceeding—Gateway 1 to PBX A	Gateway 1 sends a Call Proceeding   message to PBX A to acknowledge the Call Setup request.
4.	100 Trying—Cisco SIP IP phone to   Gateway 1	The Cisco SIP IP phone sends a SIP   100 Trying response to Gateway 1. The 100 Trying response indicates that   the INVITE request has been received by the Cisco SIP IP phone.
5.	180 Ringing—Cisco SIP IP phone to   Gateway 1	The Cisco SIP IP phone sends a SIP   180 Ringing response to Gateway 1. The 180 Ringing response indicates   that the user is being alerted.
6.	Alerting—Gateway 1 to PBX A	Gateway 1 sends an Alert message to   User A. The Alert message indicates that Gateway 1 has received a 180 Ringing   response from the Cisco SIP IP phone. User A hears the ringback tone that   indicates that User B is being alerted.
7.	200 OK—Cisco SIP IP phone to Gateway   1	The Cisco SIP IP phone sends a SIP   200 OK response to Gateway 1. The 200 OK response notifies Gateway 1 that the   connection has been made.
8.	Connect—Gateway 1 to PBX A	Gateway 1 sends a Connect message to   PBX A. The Connect message notifies PBX A that the connection has been made.
9.	Connect ACK—PBX A to Gateway 1	PBX A acknowledges Gateway 1's   Connect message.
10.	ACK—Gateway 1 to Cisco SIP IP phone	Gateway 1 sends a SIP ACK to the   Cisco SIP IP phone. The ACK confirms that Gateway 1 has received the 200 OK   response. The call session is now active.
11.	BYE—Cisco SIP IP phone to   Gateway 1	User B terminates the call session at   his Cisco SIP IP phone and the phone sends a SIP BYE request to Gateway 1.   The BYE request indicates that User B wants to release the call.
12.	Disconnect—Gateway 1 to PBX A	Gateway 1 sends a Disconnect message   to PBX A.
13.	Release—PBX A to Gateway 1	PBX A sends a Release message to   Gateway 1.
14.	200 OK—Gateway 1 to Cisco SIP IP   phone	Gateway 1 sends a SIP 200 OK response   to the Cisco SIP IP phone. The 200 OK response notifies the phone that   Gateway 1 has received the BYE request.
15.	Release Complete—Gateway 1 to PBX A	Gateway 1 sends a Release Complete   message to PBX A and the call session is terminated.

2. Call flow between Gateway-to-Cisco SIP IP Phone Call—Successful Call Setup and Call Hold

Below diagram illustrates a successful gateway-to-Cisco SIP IP phone call setup and call hold. In this scenario, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to Gateway 1 (SIP Gateway) via a T1/E1. User B is located at a Cisco SIP IP phone. Gateway 1 is connected to the Cisco SIP IP phone over an IP network.
The call flow is as follows:
1. User A calls User B.
2. User B answers the call.
3. User B puts User A on hold.
4. User B takes User A off hold.

Step	Action	Description
1.	Setup—PBX A to Gateway 1	Call setup is initiated between PBX A   and Gateway 1. The call setup includes the standard transactions that take   place as User A attempts to call User B.
2.	INVITE—Gateway 1 to Cisco SIP IP   phone	Gateway 1 maps the SIP URL phone   number to a dial peer. The dial peer includes the IP address and the port   number of the SIP enabled entity to contact. Gateway 1 sends a SIP   INVITE request to the address it receives as the dial peer, which, in this   scenario, is the Cisco SIP IP phone. In the INVITE request: The        IP address of the Cisco SIP IP phone is inserted in the Request-URI        field. PBX        A 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. The        port on which the gateway is prepared to receive the RTP data is        specified.
3.	Call Proceeding—Gateway 1 to PBX A	Gateway 1 sends a Call Proceeding   message to PBX A to acknowledge the Call Setup request.
4.	100 Trying—Cisco SIP IP phone to   Gateway 1	The Cisco SIP IP phone sends a SIP   100 Trying response to Gateway 1. The 100 Trying response indicates that the   INVITE request has been received by the Cisco SIP IP phone.
5.	180 Ringing—Cisco SIP IP phone to   Gateway 1	The Cisco SIP IP phone sends a SIP   180 Ringing response to Gateway 1. The 180 Ringing response indicates   that the user is being alerted.
6.	Alerting—Gateway 1 to PBX A	Gateway 1 sends an Alert message to   User A. The Alert message indicates that Gateway 1 has received a 180 Ringing   response from the Cisco SIP IP phone. User A hears the ringback tone   that indicates that User B is being alerted.
7.	200 OK—Cisco SIP IP phone to Gateway   1	The Cisco SIP IP phone sends a SIP   200 OK response to Gateway 1. The 200 OK response notifies Gateway 1 that the   connection has been made.
8.	Connect—Gateway 1 to PBX A	Gateway 1 sends a Connect message to   PBX A. The Connect message notifies PBX A that the connection has been made.
9.	ACK—Gateway 1 to Cisco SIP IP phone	Gateway 1 sends a SIP ACK to the   Cisco SIP IP phone. The ACK confirms that User A has received the 200 OK   response. The call session is now active.
10.	Connect ACK—PBX A to Gateway 1	PBX A acknowledges Gateway 1's   Connect message.
11.	INVITE—Cisco SIP IP phone to Gateway   1	User B puts User A on hold. The Cisco   SIP IP phone sends a SIP INVITE request to Gateway 1.
12.	200 OK—Gateway 1 to Cisco SIP IP   phone	Gateway 1 sends a SIP 200 OK response   to the Cisco SIP IP phone. The 200 OK response notifies the Cisco SIP IP   phone that the INVITE was successfully processed.
13.	ACK—Cisco SIP IP phone to Gateway 1	The Cisco SIP IP phone sends a SIP   ACK to Gateway 1. The ACK confirms that the Cisco SIP IP phone has received   the 200 OK response. The call session is now temporarily inactive. No RTP   packets are being sent.
14.	INVITE—Cisco SIP IP phone to Gateway   1	User B takes User A off hold. The   Cisco SIP IP phone sends a SIP INVITE request to Gateway 1.
15.	200 OK—Gateway 1 to Cisco SIP IP   phone	Gateway 1 sends a SIP 200 OK response   to the Cisco SIP IP phone. The 200 OK response notifies the Cisco SIP IP   phone that the INVITE was successfully processed.
16.	ACK—Cisco SIP IP phone to Gateway 1	The Cisco SIP IP phone sends a SIP   ACK to Gateway 1. The ACK confirms that the Cisco SIP IP phone has received   the 200 OK response. The call session is now active.

3. Call flow between Cisco SIP IP Phone-to-Cisco SIP IP Phone Simple Call Hold

Below diagram illustrates a successful call between Cisco SIP IP phones in which one of the participants places the other on hold and then returns to the call. In this call flow scenario, the two end users are User A and User B. User A and User B are both using Cisco SIP IP phones, which are connected via an IP network.
The call flow scenario is as follows:
1. User A calls User B.
2. User B answers the call.
3. User B places User A on hold.
4. User B takes User A off hold.
5. The call continues.

Step	Action	Description
1.	INVITE—Cisco SIP IP phone A to Cisco   SIP IP phone B	Cisco SIP IP phone A sends a SIP   INVITE request to Cisco SIP IP phone B. 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 e-mail 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 distinquishes that the Request-URI address is a telephone        number rather than a username. Cisco        SIP IP phone A 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.	180 Ringing—Cisco SIP IP phone B to   Cisco SIP IP phone A	Cisco SIP IP phone B sends a SIP 180   Ringing response to Cisco SIP IP phone A.
3.	200 OK—Cisco SIP IP phone B to Cisco   SIP IP phone A	Cisco SIP IP phone B sends a SIP 200   OK response to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP   IP phone A that the connection has been made. If Cisco SIP IP phone B supports the   media capability advertised in the INVITE message sent by Cisco SIP IP phone   A, it advertises the intersection of its own and Cisco SIP IP phone A's media   capability in the 200 OK response. If Cisco SIP IP phone B does not support   the media capability advertised by Cisco SIP IP phone A, it sends back a   400 Bad Request response with a 304 Warning header field.
4.	ACK—Cisco SIP IP phone A to Cisco SIP   IP phone B	Cisco SIP IP phone A sends a SIP ACK   to Cisco SIP IP phone B. The ACK confirms that Cisco SIP IP phone A has   received the 200 OK response from Cisco SIP IP phone B. The ACK might contain a message body   with the final session description to be used by Cisco SIP IP phone B. If the   message body of the ACK is empty, Cisco SIP IP phone B uses the session   description in the INVITE request.
A two-way RTP channel is established between Cisco SIP IP   phone A and Cisco SIP IP phone B.
5.	INVITE—Cisco SIP IP phone B to Cisco   SIP IP phone A	Cisco SIP IP phone B sends a mid-call   INVITE to Cisco SIP IP phone A with new Session Description Protocol (SDP)   session parameters (IP address), which are used to place the call on   hold. Call_ID=1 SDP: c=IN IP4 0.0.0.0 The c= SDP field of the SIP INVITE   contains an 0.0.0.0. This places the call in hold.
6.	200 OK—Cisco SIP IP phone A to Cisco   SIP IP phone B	Cisco SIP IP phone A sends a SIP 200   OK response to Cisco SIP IP phone B.
7.	ACK—Cisco SIP IP phone B to Cisco SIP   IP phone A	Cisco SIP IP phone B sends a SIP ACK   to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has   received the 200 OK response from Cisco SIP IP phone A.
The RTP channel between Cisco SIP IP phone A and Cisco SIP   IP phone B is torn down.
8.	INVITE—Cisco SIP IP phone B to Cisco   SIP IP phone A	Cisco SIP IP phone B sends a mid-call   INVITE to Cisco SIP IP phone A with the same call ID as the previous INVITE   and new SDP session parameters (IP address), which are used to reestablish   the call. Call_ID=1 SDP: c=IN IP4 181.23.250.2 To reestablish the call between phone   A and phone B, the IP address of phone B is inserted into the c= SDP field.
9.	200 OK—Cisco SIP IP phone A to Cisco   SIP IP phone B	Cisco SIP IP phone A sends a SIP 200   OK response to Cisco SIP IP phone B.
10.	ACK—Cisco SIP IP phone B to Cisco SIP   IP phone A	Cisco SIP IP phone B sends a SIP ACK   to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has   received the 200 OK response from Cisco SIP IP phone A.
A two-way RTP channel is reestablished between IP phone A   and IP phone B.