Upload File

sip-cucm

66
Configure and Troubleshoot Call Forward to the PSTN using SIP Trunks Introduction With the increased usage of mobility features and work from home scenarios, there is increased demand for the ability to transfer incoming calls from the PSTN back out to different PSTN destinations. When using SIP trunks for PSTN connectivity these calling scenarios often fail due to call validation. This document is a guide to configuration and troubleshooting of these call flows. Core Issue All outbound PSTN SIP calls are validated by the SIP Trunk provider to ensure the calls are valid and not toll fraud attempts. The methods of call validation can vary from provider to provider, and many involve multiple methods for the same call. This becomes a concern when using the default settings in a CUCM w/CUBE topology and attempting to call forward an inbound PSTN call back out to the PSTN. One of the most common validation methods is for the SIP provider to examine the "From" field in the incoming INVITE of a call and make sure it matches to a known DID number for that customer. The default setting in CUCM for forwarding calls is to maintain the CLID of the calling originator. This causes the "From" field of an outgoing INVITE to contain the CLID number of the original PSTN caller, and not a valid DID belonging to the customer. When the provider sees this with no additional information, it typically will reject the call setup attempt or ignore it completely. Resolution There are three common solutions to this issue. The first is to alter the "From" field so that the CUCM will send the information of the redirecting number instead of the call originator. In this scenario the "From" field will contain a valid customer DID number, and the call will validate. The advantage of this technique is that it works with virtually all SIP providers. The disadvantage is that the receiving party of the forwarded call will only see the caller-ID of the number that was set to forward (typically their own office DID number). They will not see the caller-ID of the original caller, and therefore will not know who is calling prior to answering the call. Here are the steps to use the first method: -Navigate to the SIP Trunk page in CUCM -Navigate to "Outbound Calls" section of the page -Change the value in the drop down entitled "Calling Party Selection" to "Last Redirect Number (External)" -Save the change, and apply the change (may drop calls why you press apply, so be careful with this change during business hours) A second method is also often used, though it requires the SIP provider to validate calls through a different method. This technique involves adding a p-asserted identity line in the outbound INVITE containing a valid DID. The advantage of this technique is that the "From"

Upload: theajkumar

Post on 18-Aug-2015

216 views

Category:

Documents


3 download

Report

DESCRIPTION

SIP-CUCM

TRANSCRIPT

Configure and Troubleshoot Call Forward to the PSTN using SIP Trunks Introduction With the increased usage of mobility features and work from home scenarios, there is increased demand for the ability to transfer incoming calls from the PSTN back out to different PSTN destinations.When using SIP trunks for PSTN connectivity these calling scenarios often fail due to call validation.This document is a guide to configuration and troubleshooting of these call flows. Core Issue All outbound PSTN SIP calls are validated by the SIP Trunk provider to ensure the calls are valid and not toll fraud attempts.The methods of call validation can vary from provider to provider, and many involve multiple methods for the same call.This becomes a concern when using the default settings in a CUCM w/CUBE topology and attempting to call forward an inbound PSTN call back out to the PSTN.One of the most common validation methods is for the SIP provider to examine the "From" field in the incoming INVITE of a call and make sure it matches to a known DID number for that customer.The default setting in CUCM for forwarding calls is to maintain the CLID of the calling originator.This causes the "From" field of an outgoing INVITE to contain the CLID number of the original PSTN caller, and not a valid DID belonging to the customer.When the provider sees this with no additional information, it typically will reject the call setup attempt or ignore it completely. Resolution There are three common solutions to this issue.The first is to alter the "From" field so that the CUCM will send the information of the redirecting number instead of the call originator.In this scenario the "From" field will contain a valid customer DID number, and the call will validate.The advantage of this technique is that it works with virtually all SIP providers.The disadvantage is that the receiving party of the forwarded call will only see the caller-ID of the number that was set to forward (typically their own office DID number).They will not see the caller-ID of the original caller, and therefore will not know who is calling prior to answering the call.Here are the steps to use the first method: -Navigate to the SIP Trunk page in CUCM -Navigate to "Outbound Calls" section of the page -Change the value in the drop down entitled "Calling Party Selection" to "Last Redirect Number (External)" -Save the change, and apply the change (may drop calls why you press apply, so be careful with this change during business hours) A second method is also often used, though it requires the SIP provider to validate calls through a different method.This technique involves adding a p-asserted identity line in the outbound INVITE containing a valid DID.The advantage of this technique is that the "From" field retains the calling originator's information so that the recipient of the call can see who is calling on their caller-ID.The disadvantage of this technique is that it is not universally used, and customers need to check with their SIP providers to make sure they will validate calls based on the p-asserted identity value instead of the "from" field value.Here are the steps to use the second technique when using a CUBE gateway: -Log into the CUBE router -Add the following SIP profile (make sure to use a unique profile number if you have existing SIP profiles, or add it to your outbound SIP profile in use.Also make sure to use a valid DID number and SBC URL information.) voice class sip-profiles 1 request INVITE sip-header P-Asserted-Identity add "P-Asserted-Identity:" -Add the following configuration line to the dial-peer being matched to place the outbound call to the SIP provider: voice-class sip profiles 1 Make sure that the SIP Profile contains a valid DID with your SIP provider.Also, most providers will look for a fully qualified domain name in the PAI, as opposed to an IP address.Be use to use the FQDN in the profile, even if you are routing the calls directly to the provider's IP address. The third method is similar to the second but instead of a PAI line, this uses a Diversion Header.The Diversion Header is added to the outbound INVITE and contains a DID number that the provider can validate the call with.Like with the second option, the advantage of this technique is that the "From" field retains the calling originator's information so that the recipient of the call can see who is calling on their caller-ID.The disadvantage of this technique is that it is not universally used, and customers need to check with their SIP providers to make sure they will validate calls based on the diversion header value instead of the "from" field value.Here are the steps to use the third technique when using a CUBE gateway: -Navigate to SIP Trunk page in CUCM -Navigate to "Outbound Calls" section of the page -Check the "Redirecting Diversion Header Delivery - Outbound" Check box -Save the change, and apply the change (may drop calls why you press apply, so be careful with this change during business hours) -Log into the CUBE router -Add the following SIP profile (make sure to use a unique profile number if you have existing SIP profiles, or add it to your outbound SIP profile in use.Also make sure to use a valid DID number and SBC URL information.) voice class sip-profiles 1 request INVITE sip-header Diversion modify "" "" -Add the following configuration line to the dial-peer being matched to place the outbound call to the SIP provider: voice-class sip profiles 1 Make sure that the SIP Profile contains a valid DID with your SIP provider.Also, most providers will look for a fully qualified domain name in the diversion header, as opposed to an IP address.Be use to use the FQDN in the profile, even if you are routing the calls directly to the provider's IP address. Troubleshooting The following debugs are useful in this call scenario: debug ccsip messages debug voip ccapi inout When reading these debugs keeping the different call legs straight can get confusing.It is recommended to use an application such as Notepad ++, and to mark the Call ID of each call leg traversing the CUBE.The goal of these debugs is to check that the outbound INVITE for the forwarded call contains either the correct "from" field, or the correct "p-asserted identity" or "diversion header" field.If using the "from" field method, check that the SIP INVITE coming from the CUCM contains the full 10 digit DID number for the last redirecting party, and that this value is the same in the INVITE going to the provider.If using either the "p-asserted identity" method or the "diversion header" method, make sure that the outgoing call is matching the correct dial-peer that has the voice-class sip profile set on it.If it is matching a different dial-peer, add the sip profile to that dial-peer. Incoming Dial-peer matching on IP AddressIntroduction Starting IOS version 15.1(2)T, we canmatch inbound dial-peers via IP Address or hostname. This enablesCUBE/TDM-SIP to connect to two or more different ITSPs allowing specificcall routing, codec selection, digit manipulation, CAC, QoS, orsecurity policies for each ITSP. Feature Overview Dial-peerselection is based on immediate SIP neighbor's address information andapplicable only to incoming SIP calls. The address information isretrieved from the VIA header of the incoming message, which is thenused to lookup the dial-peer that has the best match for the criteriaselected. The lookup will first attempt to match a dial-peer with theaddress information in the following order: Via header Request URI To URI From URI Called Number If none of the parameters match, then the default inbound dial-peer is matched. Thisfeature also allows for Generic DNS Caching framework for faster FQDNto IP Address lookup. For a configured FQDN, the DNS Caching frameworkresolves the FQDN and stores the corresponding set of IP addresses forit. The framework also takes care of the regular DNS refreshes for theFQDN. For a dial-peer match to be done, if the incoming Via header hasan IP address and the configuration has an FQDN, then the correspondingresolved addressed of this FQDN is queried from the DNS CachingFramework. Call Flow ITSP1 ---> SIP --> Call from source address 172.16.1.10 -----> | ----> CUBE - SIP - CUCM - IP Phones ITSP2 ---> SIP --> Call from source address 172.31.10.10 ---> Sample Config !To handle incoming calls from ITSP1 voice class uri 1001 sip host ipv4:172.16.1.10 dial-peer voice 1 voip description Calls from ITSP1 session protocol sipv2 incoming uri via 1001 max-connection 10 codec g711ulaw acc-qos controlled-load req-qos controlled-load !To handle incoming calls from ITSP2 voice class uri 1002 sip host ipv4:172.31.10.10 dial-peer voice 1 voip description Calls from ITSP1 incoming uri via 1002 session protocol sipv2 max-connection 30 codec g729r8 How to Check Active Call Count on SIP Problem Description Requirement / Issue: Service Provider is using ISR 3945 as a CUBE to connect to his interconnect Service Provider over SIP trunks. ISP is interested to know the total active SIP Calls on the trunk (not call legs). Is there a way we could arrive at the total active calls from the calllegs and identify the SIP-to-SIP calls on Cisco Unified Border Element (CUBE)? Solution Show commands to Identify the active call count on SIP: Show commands SBC03#Show call active voice compact Number of call-legs counted during viewing: 1448 SBC03#Show voip rtp connections Found 1459 active RTP connections SBC03#show call active voice brief | incl call-legs Telephony call-legs: 0 SIP call-legs: 1053 H323 call-legs: 0 Call agent controlled call-legs: 0 SCCP call-legs: 410 Multicast call-legs: 0 Total call-legs: 1463 Telephony call-legs: 0 SIP call-legs: 1050 H323 call-legs: 0 Call agent controlled call-legs: 0 SCCP call-legs: 410 Multicast call-legs: 0 Total call-legs: 1460 is not equal to the initial count. Some call-legs were Number of call-legs counted during viewing: 1460 SBC03# SBC03# SBC03# SBC03#sh sip-ua call su Total SIP call legs:1066, User Agent Client:526, User Agent Server:540 SBC03#sh call active voice summary Telephony call-legs: 0 SIP call-legs: 38 H323 call-legs: 0 Call agent controlled call-legs: 0 SCCP call-legs: 0 Multicast call-legs: 0 Total call-legs: 38 SBC03#sh sip-ua calls summaryTotal SIP call legs:44, User Agent Client:19, User Agent Server:25 SBC03#sh call active voice summary Telephony call-legs: 0 SIP call-legs: 38 H323 call-legs: 0 Call agent controlled call-legs: 0 SCCP call-legs: 0 Multicast call-legs: 0 Total call-legs: 38 Since the above example is only on SIP-SIP calls you can see from active call Summary No. of SIP-SIP Calls = SIP call leg / 2= 19 But there can be more on total legs as there can some calls being generated. If you have MTP/transcoder / conference then those legs will be more than the actual call leg. So we should take no. of SIP legs /2 for SIP-SIP calls. Working concept of SCCP & SIP Phones and the Dial rules Introduction This document intends to help the beginners to understand the basics of IP Telephony. It explains the working concept of the SCCP & SIP Phones and the Dial rules, digit forwarding methods to initiate a call. IP Phone Registration Process As a prerequisite understand the IP Phone Registration Process. Refer the below link to understand the SCCP & SIP Phone Registration Process. IP Phone, SCCP & SIP Phone Registration Process with CUCM SCCP & SIP Phone Digit forwarding methods Digit forwarding methods supported, SCCP Phones: Digit-by-Digit SIP Phones: Enbloc, KPML (default on newer phones), SIP dial rules What is KPML? It is nothing but Keypad Markup Language (KPML). Call came from an SIP Phone using KPML, CUCM receives, interprets and analyzes the dial plan on a digit-by-digit basis. Cisco SIP Phones that support KPML use digit-by-digit dialing by default. KPML is not supported on older SIP Phones. Type A phones. How SCCP & SIP Phone Works? SCCP Phones: Cisco IP Phones using SCCP, TCP port 2000 report every user input even to CUCM immediately. As soon as the user goes off-hook, a signaling message is sent from the phone to the CUCM server with which it is registered. A user goes off-hook and then dials extension 1000. Each event is reported to CUCM in real time. All the call progress feedback provided by CUCM to the end user on the Cisco IP Phone, Screen display messages showing calling or called party, dial tone, secondary dial tone, ring back, reorder tone and so on is initiated by an SCCP message sent from CUCM to the Cisco IP Phone. Skinny Client Control Protocol (SCCP) is a stimulus/response protocol where the endpoint sends user input (stimulus) and expects some type of response from the server instructing the endpoint about what to do. Note: - It is not possible to configure dial plan information (dial rules) on Cisco IP Phones using SCCP. All dial plan functionality is contained in the CUCM cluster with an SCCP phone. A user dialing an international pattern that is denied by the end user's CoS deployed in CUCM will result in the reorder tone ie busy signal that is played to the calling party letting the party know that the "Call could not be completed as dialed". If calls to the 976 area code are denied based on the calling party's configured CoS, a reorder tone is sent to the calling party phone as soon as the user dials 91976. SIP IP Phones: Type A SIP Phones: Cisco Unified IP Phone models 7905, 7912, 7940 and 7960 Type A SIP Phones support SIP dial rules, which are configured in CUCM and downloaded to the IP Phone at boot time. It does not support KPML. SIP dial rules will enable dial tone and traditional phone functionality on CUCM. Type A SIP Phones: No Dial rules Type A Cisco IP Phones using SIP firmware without SIP dial rules do not deliver a dial tone to the calling party when the calling party goes off-hook with the handset or speaker phone. All digits are sent to CUCM enbloc after the user completes the dialing and press the Dial softkey. Figure shows, User making a call to extension 1000. The user dials 1000 followed by pressing the Dial soft key. The Cisco IP Phone sends a SIP INVITE message to CUCM with all dialed digits (enbloc). CUCM performs digit analysis and provides a call progress message to the IP Phone. Type A SIP Phones: Dial rules SIP dial rules allow SIP Phones to emulate the functionality of an SCCP Phone with dial tone and digit-by-digit pattern analysis. When SIP dial rules are leveraged, a user receives dial tone when going off-hook. This functionality is different than the default functionality on Cisco Type A phones converted to SIP, where there are no local dial rules. Dialed digits are processed against the local SIP dial rules in real time. If a user dials a phone number that is rejected by the local SIP dial rules, for example pay dialing beginning with 9-1900 the call is dropped without being forwarded to CUCM. SIP dial rules can help minimized overhead bandwidth consumption and CUCM processor overhead. A SIP INVITE message with enbloc signaling is sent from the Cisco SIP IP Phone to CUCM when the SIP dial rule of the Cisco IP Phone recognizes and permits the dialed pattern. End user do not need to press the Dial key like they had to on Cisco SIP type A phones. SIP dial rules allow Type A Phones to emulate SCCP and traditional phone systems while also providing processing and signaling overhead benefits. Figure illustrates a phone configured to recognize all four-digit patterns beginning with a leading digit of 1. This pattern has an associated timeout value of 0. All user input actions matching the pattern will trigger the sending of the SIP INVITE message to CUCM immediately, without requiring the user to press the Dial key. Type B SIP Phones: Cisco IP Phone models 79x1, 79x2, 79x5, 7970 and 7960 Type B and new model phones supports KPML and SIP dial rules. KPML is turned on by default on all Type B phone models 79x1, 79x2, 79x5, 7970 and7960 Type B SIP Phones: No Dial Rules Cisco Type B SIP IP Phones offer functionality based on the KPML standard to report user activities. Each user input event (dialed digit or softkey/button) generates a KPML message to CUCM. This mode of operation emulates a similar end-user experience to that of phones using SCCP. Type B SIP Phones: Dial Rules Cisco Type B SIP Phones offer functionality based SIP INVITE Message. Every key the end user presses triggers an individual SIP message. The first event is communicated with a SIP INVITE, but subsequent messages use SIP NOTIFY messages. The SIP NOTIFY messages send KPML events corresponding to any buttons or soft keys pressed by the user. Cisco Type B SIP IP Phones with SIP dial rules operate in the same manner as Cisco Type A phones with dial rules. Figure illustrates the enbloc signaling used with SIP dial rules. Note: Cisco SIP Phones that support KPML use digit-by-digit dialing by default. KPML is not supported on older Cisco Type A SIP Phones. Type A phones only support enbloc dialing when using SIP firmware. UNDERSTANDING SIP TRACES SIP traces provide key information in troubleshooting SIP Trunks, SIP endpoints and other SIP related issues. Even though these traces are in clear text, these texts can be gibberish unless you understand fully what they mean. This document attempts to break down each component of the SIP interaction using a practical approach. We will look at various logs, the SIP messages, headers, SDP information and try to figure out what is going on in a sip voice call transaction. In as much as I will try to define the under lying layer of the SIP messaging, this document will not go into in-depth analysis of the SIP protocol, so it is advisable to understand SIP protocol technology to be able to understand sip traces. One key element of troubleshooting is this: To fix a problem, you need to understand the issue, how it works before you can restore it to order. One popular debug used in troubleshooting a sip solution on a cisco IOS router is

Debug ccsip messages.

To understand The output generated by this debug..We need to understand the Key/fundamental sip messages exchanged during a sip voice call.. 1. Invite 2. Trying 3. Ringing 4. ACK 5. OK

We will look at these messages as we try to understand the debugs. These messages are key in knowing whats going on. They help us to understand the language been spoken so we are not lost like a non French speaking man in Paris! Ok enough of grammars, lets dive in! Ready? INVITE: An Invite is a SIP requests called methods. There are Six SIP methods described in the SIP specification document RFC 3261 [1]. The INVITE, REGISTER, BYE, ACK, CANCEL, and OPTIONS methods are the original six methods in SIP.

The INVITE method is used to establish media sessions between user agents. In telephony, it is similar to a Setup message in ISDN

An INVITE usually has a message body containing the media information of the caller. The message body can also contain other session information, such as a resource list in the case of an early offer. If an INVITE does not contain media information, the ACK contains the media information of the UAC.

To identify the caller, the called number, the media information and resources advertised in the Invite, SIP invites use headers. Headers are key parameters within the SIP invite and we shall look at them so as to gain full clarity of whats going on.

Lets look at a sample SIP trace from CUCM. Note this is very similar to what a debug ccsip messages will produce on a CUBE gateway.

Here is the call setup for this trace

CUCM----------sip trunk------>CUBE---------SIP Trunk--------------->ITSP (10.105.80.114)(10.105.80.174)

INVITE with SDP.

INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.105.80.114:5060;branch=z9hG4bK98e4117d52a6 From: "Solihull" ;tag=25526~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-551664735 To: Date: Mon, 02 Apr 2012 18:12:31 GMT Call-ID: [email protected] Supported: timer,resource-priority,replaces Min-SE: 1800 User-Agent: Cisco-CUCM8.6 Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY CSeq: 101 INVITE Expires: 180 Allow-Events: presence, kpml Supported: X-cisco-srtp-fallback Supported: Geolocation Call-Info: ;method="NOTIFY;Event=telephone-event;Duration=500" Cisco-Guid: 1752700672-0000065536-0000007823-0237529354 Session-Expires: 84600 Contact: Max-Forwards: 70 Content-Length: 0 Content-Type: application/sdp Content-Length: 238

v=0 o=CiscoSystemsCCM-SIP 811669 1 IN IP4 10.105.40.14 s=SIP Call c=IN IP4 10.133.92.102 t=0 0 m=audio 25268 RTP/AVP 18 101 a=rtpmap:18 G729/8000 a=ptime:20 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15

Now lets break it up or dissect this piece of information.

As we can see there are lots of headers in this invite

Via To From Call-ID CSeq Contact Max-Forwards Expires

The INVITE header

INVITE sip:[email protected]:5060 SIP/2.0

This is the first part of the trace usually refrred to as the Request-URI This shows four key things 1. The called number 2. The device responsible for the called number or the device through which the called number will be routed 3. SIP Port number 4. Sip Version..

So here we see the called number is: 14107584528207 The gateway responsible for routing to this number is 10.105.80.174 SIP port is 5060 and the Sip version is 2.0

The Via Header:

Via: SIP/2.0/UDP 10.105.80.114:5060;branch=z9hG4bK98e4117d52a6

The required Via header field is used to record the SIP route taken by a request and is used to route a response back to the originator. A UA generating a request records its own address in a Via header field.

Here we see that CUCM is the UA generating this invite and it stamps it IP on the call. This helps identify the origin of the call. Via header fields contain protocol name, version number, and transport (SIP/2.0/UDP, SIP/2.0/TCP, etc)

The To and From Headers

From: ;tag=25526~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-551664735

To: sip:[email protected]

The next header fields are the To and From header fields, which show the originator and destination of the SIP request.

Note that the To and From header fields are not reversed in the response message as one might expect them to be. This is because the To and From header fields in SIP are defi ned to indicate the direction of the request, not the direction of the message. Since CUBE--------------->CUCM---------------->IP PHONE

ITSP: 10.10.33.132 CUBE:10.100.0.74 CUCM:10.100.0.14

1. An inbound call is received on the CUBE from the ITSP. This invite was sent with SDP. NB that this inbound leg of this call will have a unique call ID that shows the origin of the call, highlighted below.

Received: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bK9377fo00cg5ha7l0g3t0.1 From: ;tag=1526438727-1338998848384- To: "voice-lab-aokanlawon" Call-ID: [email protected] CSeq: 558267841 INVITE Contact: Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY Accept: multipart/mixed,application/media_control+xml,application/sdp Supported: Max-Forwards: 69 Content-Type: application/sdp Content-Length: 207 v=0 o=BroadWorks 161384582 1 IN IP4 10.10.33.132 s=- c=IN IP4 10.10.33.132 t=0 0 m=audio 11164 RTP/AVP 18 0 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=fmtp:18 annexb=no

+++From our understanding of the traces, we see that the call originates from a device called Broadworks, which advertises G711a, G711u, G729 and uses rtp-nte for DTMF. We also see the IP address for the CUBE to stream its RTP to.+++++

2. A new Invite Sent to CUCM.

After the CUBE receives the invite, it sends an invite to cucm based on the dial-peers configured.

NB: that this new invite is sent with a new CALL-ID. This is very important in understanding the order of thigs especially when troubleshooting issues. We can also see that the CUBE advertises all its SDP attributes, codec, dtmf supported, fax etc.

002791: Jun6 16:07:28.394: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859 Remote-Party-ID: ;party=calling;screen=no;privacy=off From: ;tag=4C85762C-1A2D To: Date: Wed, 06 Jun 2012 16:07:28 GMT Call-ID: [email protected] Supported: timer,resource-priority,replaces,sdp-anat Min-SE:1800 Cisco-Guid: 2352544350-2938638817-2514718541-1568562753 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1338998848 Contact: Expires: 180 Allow-Events: kpml, telephone-event Max-Forwards: 68 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 355 v=0 o=CiscoSystemsSIP-GW-UserAgent 8773 2764 IN IP4 10.100.0.74 s=SIP Call c=IN IP4 10.100.0.74 t=0 0 m=audio 19264 RTP/AVP 18 0 8 100 101 c=IN IP4 10.100.0.74 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15

3. Next the CUBE sends a trying to ITSP. Trying simply means: I am looking for the number you have requested.

002792: Jun6 16:07:28.394: //260862/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bK9377fo00cg5ha7l0g3t0.1 From: ;tag=1526438727-1338998848384- To: "voice-lab-aokanlawon" Date: Wed, 06 Jun 2012 16:07:28 GMT Call-ID: [email protected]

CSeq: 558267841 INVITE Allow-Events: kpml, telephone-event Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0

4. Next the CUBE receives a trying from CUCM. The call-ID help us to know where these responses are coming from.

002793: Jun6 16:07:28.396: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 100 Trying Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859 From: ;tag=4C85762C-1A2D To: Date: Wed, 06 Jun 2012 16:07:28 GMT Call-ID: [email protected] CSeq: 101 INVITE Allow-Events: presence Content-Length: 0

5. Next the CUBE receives ringing from CUCM This informs the CUBE that the called endpoint is ringing

002794: Jun6 16:07:28.412: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 180 Ringing Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859 From: ;tag=4C85762C-1A2D To: ;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854 Date: Wed, 06 Jun 2012 16:07:28 GMT Call-ID: [email protected]

CSeq: 101 INVITE Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY Allow-Events: presence Supported: X-cisco-srtp-fallback Supported: Geolocation Contact: Content-Length: 0

6. The CUBE relays this message to the calling party

002795: Jun6 16:07:28.412: //260862/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bK9377fo00cg5ha7l0g3t0.1 From: ;tag=1526438727-1338998848384- To: "voice-lab-aokanlawon";tag=4C85763E-1CF8 Date: Wed, 06 Jun 2012 16:07:28 GMT Call-ID: [email protected]

CSeq: 558267841 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: kpml, telephone-event Remote-Party-ID: ;party=called;screen=no;privacy=off Contact: Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0

7. Now the CUBE receives a 200 ok from CUCM. Please note that some elements of the SDP has changed

c=IN IP4 10.100.20.10------------------------IP address to send RTP stream to t=0 0 -------------------------------------------Duration of the call m=audio 16730 RTP/AVP 18 101---------Codec to use for call and DTMF type to use a=rtpmap:18 G729/8000-------------------Codec = G729

002796: Jun6 16:07:28.556: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859 From: ;tag=4C85762C-1A2D To: ;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854 Date: Wed, 06 Jun 2012 16:07:28 GMT Call-ID: [email protected] CSeq: 101 INVITE Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY Allow-Events: presence, kpml Supported: replaces Supported: X-cisco-srtp-fallback Supported: Geolocation Session-Expires:84600;refresher=uas Require:timer Contact: Content-Type: application/sdp Content-Length: 237 v=0 o=CiscoSystemsCCM-SIP 811674 1 IN IP4 10.100.0.14 s=SIP Call c=IN IP4 10.100.20.10 t=0 0 m=audio 16730 RTP/AVP 18 101 a=rtpmap:18 G729/8000 a=ptime:20 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15

8. CUBE sends an ACK to CUCM to acknowledge the last 200 Ok message

002797: Jun 6 16:07:28.556: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg: Sent: ACK sip:[email protected]:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953DC95 From: ;tag=4C85762C-1A2D To: ;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854 Date: Wed, 06 Jun 2012 16:07:28 GMT Call-ID: [email protected] Max-Forwards: 70 CSeq: 101 ACK Allow-Events: kpml, telephone-event Content-Length: 0

9. CUBE then sends a 200 OK to ITSP with the SDP attributes to use for the Call based on what it received from CUCM.

Sent: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.100.0.14:5060;branch=z9hG4bK198a0b7ee5d33c From: ;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854 To: ;tag=4C85762C-1A2D Date: Wed, 06 Jun 2012 16:07:28 GMT Call-ID: [email protected] CSeq: 101 SUBSCRIBE Content-Length: 0 Contact: Expires: 7200 Sent: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bK9377fo00cg5ha7l0g3t0.1 From: ;tag=1526438727-1338998848384- To: "voice-lab-aokanlawon";tag=4C85763E-1CF8 Date: Wed, 06 Jun 2012 16:07:28 GMT Call-ID: [email protected] CSeq: 558267841 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: kpml, telephone-event Remote-Party-ID: ;party=called;screen=no;privacy=off Contact: Supported: replaces Supported: sdp-anat Server: Cisco-SIPGateway/IOS-12.x Supported: timer Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 270 v=0 o=CiscoSystemsSIP-GW-UserAgent 7413 6169 IN IP4 10.100.0.74 s=SIP Call c=IN IP4 10.100.0.74 t=0 0 m=audio 29626 RTP/AVP 18 101 c=IN IP4 10.100.0.74 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20

10. CUBE then receives an ACK

002803: Jun6 16:07:28.594: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: ACK sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0.1 From: ;tag=1526438727-1338998848384- To: "voice-lab-aokanlawon";tag=4C85763E-1CF8 Call-ID: [email protected]

CSeq: 558267841 ACK Contact: Max-Forwards: 69 Content-Length: 0

11. Finally the call is ended. Now when troubleshooting the direction of call termination is important. In this case we can see that the CUBE receives a BYE, which is the sip method for call termination. However who sent the BYE, is it CUCM or ITSPThe answer is in the Call-ID. As we call can see the CALL-ID is for the leg from the ITSP. So we see that the call was terminated from the ITSP side.

Next important thing is the cause code. The reason why the call was terminated.

CSeq: 558267842 BYE Reason: Q.850;cause=16

Here we see as normal call clearing Cause=16.

Received: BYE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0cd1hhq713.1 From: ;tag=1526438727-1338998848384- To: "voice-lab-aokanlawon";tag=4C85763E-1CF8 Call-ID: [email protected] CSeq: 558267842 BYE Max-Forwards: 69 Content-Length: 0

002809: Jun6 16:07:34.470: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0cd1hhq713.1 From: ;tag=1526438727-1338998848384- To: "voice-lab-aokanlawon";tag=4C85763E-1CF8 Date: Wed, 06 Jun 2012 16:07:34 GMT Call-ID: [email protected] Server: Cisco-SIPGateway/IOS-12.x CSeq: 558267842 BYE Reason: Q.850;cause=16 P-RTP-Stat: PS=295,OS=5900,PR=292,OR=5840,PL=0,JI=0,LA=0,DU=5 Content-Length: 0 002810: Jun6 16:07:34.470: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg: Sent: BYE sip:[email protected]:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7954021A8 From: ;tag=4C85762C-1A2D To: ;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854 Date: Wed, 06 Jun 2012 16:07:28 GMT Call-ID: [email protected] User-Agent: Cisco-SIPGateway/IOS-12.x Max-Forwards: 70 Timestamp: 1338998854 CSeq: 103 BYE Reason: Q.850;cause=16

Received: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7954021A8 From: ;tag=4C85762C-1A2D To: ;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854 Date: Wed, 06 Jun 2012 16:07:34 GMT Call-ID: [email protected] CSeq: 103 BYE Content-Length: 0

Below are a few of the Threads that we have used the indepth understanding of sip trcaes to help resolve thier issues. Please take a look as this will help you to understand better sip traces and how they play a key part in troubleshooitng issues Introduction

This document explains the basic SIP Call flow between the PBX, Gateways and SIP Phones in detail. Idea of creating this document is to help the beginners to understand the Various SIP Call flows and messages. Also this document covers the SIP Troubleshooting commands.

Prerequisites Basic knowledge about the SIP Protocol and the call flow Messages.

Call Flow Examples

1. Call Flow between PBX to Cisco SIP IP PhoneSuccessful 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.

StepActionDescription 1.SetupPBX 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.INVITEGateway 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 ProceedingGateway 1 to PBX A Gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request. 4.100 TryingCisco 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 RingingCisco 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.AlertingGateway 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 OKCisco 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.ConnectGateway 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 ACKPBX A to Gateway 1 PBX A acknowledges Gateway 1's Connect message. 10.ACKGateway 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.BYECisco 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.DisconnectGateway 1 to PBX A Gateway 1 sends a Disconnect message to PBX A. 13.ReleasePBX A to Gateway 1 PBX A sends a Release message to Gateway 1. 14.200 OKGateway 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 CompleteGateway 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 CallSuccessful 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.

StepActionDescription 1.SetupPBX 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.INVITEGateway 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 ProceedingGateway 1 to PBX A Gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request. 4.100 TryingCisco 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 RingingCisco 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.AlertingGateway 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 OKCisco 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.ConnectGateway 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.ACKGateway 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 ACKPBX A to Gateway 1 PBX A acknowledges Gateway 1's Connect message. 11.INVITECisco 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 OKGateway 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.ACKCisco 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.INVITECisco 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 OKGateway 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.ACKCisco 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.

StepActionDescription 1.INVITECisco 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:[email protected]; 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 RingingCisco 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 OKCisco 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.ACKCisco 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.INVITECisco 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 OKCisco 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.ACKCisco 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.INVITECisco 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 OKCisco 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.ACKCisco 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.

Defining SIP Port in Cisco Unified Communications Manager

SIP Troubleshooting

On Unified Communications Manager use RTMT to check SIP traces in UC Manager "debug ccsip calls" "debug ccsip all" "debug ccsip error" "debug ccsip events" "debug ccsip messages" "debug ccsip states" "show sip-ua call" - Displays active UAC and user agent server (UAS) information on sip calls " show call active voice brief" - Displays active call information for voice calls or fax transmission in progress

Check MTP configuration - MTP is required for Early offer - MTP is required on older UC Manager versions to provide supplementary services Check layer 2/3 variables

Dial-peer Codec Selection, CUCM Region Settings And Transcoders IN A SIP Deployment INTRODUCTION This document is to demonstrate how codec negotiation is done between calls involving CUBE, SIP Trunks, CUCM, IP Phones and Cisco Unity connection. In some scenarios a transcoder will be invoked and we shall look at why and how to properly design your network to know if you need a transcoder or not. This will be based on a very practical approach as seen from a production environment. The call flow will be divided into different call scenarios and we will examine what codec is used for each call and if a transcoder is needed or not. Each of the call scenarios will also be discussed based on the direction of the call; Inbound or Outbound. This is because different rules apply depending on which direction the call originates and terminate. The region settings involved in each of the call flow will also be considered as they play a key role in codec negotiation. NB: Some of the call scenario use voice-class codec on the dial-peers. There is a general good practice on using voice-class codec on CUBE. for voice-class codec to work well on cube, ensure the codec preference and order is the same on both inbound and outbound dial-peer. THE ENVIRONMENT This environment is a cluster of 8 CUCM servers with four call processing servers (CUCM service activated), two Unity connection clustered servers and two CUBES CUCM version: 8.6.2.21900-5 CUBE IOS version:c3900e-universalk9-mz.SPA.151-4.M4.bin IP Phones: 7940 and 7960 Unity connection with Sip trunk Integration:8.6.2.21900-5 CUBE is configured with early offer forced; hence all traffic from CUBE goes out with advertised SDP. Voice service voip sip early-offer forced CUCM does delayed offer. INBOUND CALLS Lets start with inbound calls: CALL SCENARIO 1, CALL FLOW ITSP--------sip----------->CUBE--------sip----->CUCM----sccp---->IP Phone SCENARIO 1------Inbound call to an IP Phone(no xcoder invoked) ++++Inbound dial-peer to CUBE++++ dial-peer voice 1 voip modem passthrough nse codec g711ulaw incoming called-number . voice-class codec 1 dtmf-relay sip-kpml rtp-nte +++++Outbound dial-peer config to CUCM++++ dial-peer voice 50 voip description Inbound calls to CUCM translation-profile outgoing IN_PORT destination-pattern 44T modem passthrough nse codec g711ulaw session protocol sipv2 session target ipv4:10.10.4.74 session transport tcp dtmf-relay rtp-nte digit-drop h245-alphanumeric voice-class codec 1 fax rate disable Region between phone and cube is set to use G711. Inbound and outbound dial-peer set to use voice class codec with g729 as preferred codec CALL ANALYSIS 1. Call arrives on CUBE and matched inbound DP=1 with voice-class codec set. 2. Call matches outbound dial-peer 50, voice-class codec set 3. When a voice-class is configured on a DP, the codec used will depend on the region setting between the source and the destination. Here, the source is cube (sip trunk), the destination is an IP Phone. Because the region setting between the CUBE and IP Phone is G711, the call will use G711. The region setting becomes the prevailing factor here. CUCM will send a 200 OK to the invite received from CUBE with the codec set between the endpoint and destination. In actual fact whatever the region setting between the IP phone and the CUBE is, thats the codec that will be used. If its G729, then the call will use G729. An abbreviated trace is shown below: Cube receives invite from ITSP with early offer and all supported codecs Received: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.106.33.24:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1 From: ;tag=451687893-1338998863036- To: " -SPK TestGrid" Content-Type: application/sdp v=0 o=BroadWorks 161384816 1 IN IP4 10.10.10.10 s=- c=IN IP4 10.10.10.10 t=0 0 m=audio 15382 RTP/AVP 18 0 8 101-------------Advertised CODECS a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=fmtp:18 annexb=no CUBE sends invite to cucm with early offer and codecs matched on voice-class codec Sent: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F Remote-Party-ID: ;party=calling;screen=no;privacy=off From: ;tag=4C85AF62-DA1 To: User-Agent: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp Content-Disposition: session;handling=required v=0 o=CiscoSystemsSIP-GW-UserAgent 6494 4459 IN IP4 10.10.4.174 s=SIP Call c=IN IP4 10.10.4.174 t=0 0 m=audio 16668 RTP/AVP 18 0 8 100 101--------->CUBE advertises Codec to CUCM c=IN IP4 10.10.4.174 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 After a couple of trying and ringing CUBE gets a 200 ok from cucm with endpoint codec and IP. Codec chosen based on the region between endpoint and CUBE sip trunk (CUBE-CUBE in this case) Received: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F From: ;tag=4C85AF62-DA1 To: ;tag=811681~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2- v=0 o=CiscoSystemsCCM-SIP 811681 1 IN IP4 10.10.4.14 s=SIP Call c=IN IP4 10.54.117.13------RTP sent directly to IP Phone t=0 0 m=audio 27770 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000---------------G711Ulaw selected to use for the call a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 A show voip rtp connection shows the flow of RTP stream for the two call legs Sh voip rtp connection: 13 91498 91499 31298 23516 10.10.4.174 10.10.10.10 (ITSP-CUBE) 14 91499 91498 17432 25092 10.10.4.174 10.54.117.13 (CUBE to IP phone) Scenario 2, Call Flow ITSP--------sip----------->CUBE(1)--------sip----->CUCM---->Ip Phone (Reg btw IP phone-Cube) SCENARIO 2------Inbound call to an IP Phone(xcoder invoked) ++++Inbound dial-peer to CUBE++++ dial-peer voice 1 voip modem passthrough nse codec g711ulaw incoming called-number . voice-class codec 1 dtmf-relay sip-kpml rtp-nte +++++Outbound dial-peer config to CUCM++++ dial-peer voice 50 voip description Inbound calls to CUCM translation-profile outgoing IN_PORT destination-pattern 44T modem passthrough nse codec g711ulaw session protocol sipv2 session target ipv4:10.10.4.74 session transport tcp dtmf-relay rtp-nte digit-drop h245-alphanumeric codec g711ulaw fax rate disable Region between phone and cube is set to use G729. Outbound dial-peer is hard coded to use g711ulaw CALL ANALYSIS 1. Call arrives on CUBE and matched inbound DP=1 with voice-class codec set. 2. Call matches outbound dial-peer 50, codec set to G711ulaw 3. At this point regardless of the region setting between the ip phone and cube or sip trunk to the CUBE, G711u will be used. This is because the CUBE sends an early offer with only g711ulaw advertised. So CUCM is forced to send an ACK back with only g711u as the codec to use for the call. The region setting between the phone and cube will now determine if a xcoder is invoked or not. Since the region setting between the phone and CUBE is set to G729 in this case, a xcoder must be invoked and available otherwise the call will fail. The two call legs look like this: Callleg1=g711..inbound call leg to CUBE (DP Is set to G711ulaw Callleg2=G729.outbound call leg to ip phone (region between phone and cube=g729). In this case which I looked at, the system was not properly designed; hence there was no transcoder available for use in the MRGL of the cube. NB: There was a transcoder in the MRG but the region between the CUBE and the transcoder was set to G729. Hence the CUBE couldnt use it. CUCM however found a transcoder in the default MRGL which was an unassigned transcoder. The problem with this is, the system administrators had no idea that calls were been redirected to this transcoder. After a while users started reporting that calls come into their phone and they are unable to pick up. When they pickup the headset, calls dont connect. This was because the remote transcoder in use didnt have enough sessions on it to support the call traffic redirected to it. The system was not designed for this transcoder to be used; hence no one made such provisions. This is why its crucial to design your system very well and to understand each element of your solution and how they interact. An abbreviated trace is shown below: Cube receives invite from ITSP with early offer and all supported codecs Received: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.106.33.24:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1 From: ;tag=451687893-1338998863036- To: " -SPK TestGrid" Content-Type: application/sdp v=0 o=BroadWorks 161384816 1 IN IP4 10.10.10.10 s=- c=IN IP4 10.10.10.10 t=0 0 m=audio 15382 RTP/AVP 18 0 8 101-------------Advertised CODECS a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=fmtp:18 annexb=no CUBE sends invite to cucm with early offer and G711 as the only advertised codec Sent: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F Remote-Party-ID: ;party=calling;screen=no;privacy=off From: ;tag=4C85AF62-DA1 To: User-Agent: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp Content-Disposition: session;handling=required v=0 o=CiscoSystemsSIP-GW-UserAgent 6494 4459 IN IP4 10.10.4.174 s=SIP Call c=IN IP4 10.10.4.174 t=0 0 m=audio 16668 RTP/AVP 0 100101-------->CUBE advertises G711u Codec to CUCM c=IN IP4 10.10.4.174 a=rtpmap:0 PCMU/8000 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 CUCM sends a 200 OK, agreeing on G711ulaw as the codec to use and the Xcoder IP for RTP streaming Received: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F From: ;tag=4C85AF62-DA1 To: ;tag=811681~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2- v=0 o=CiscoSystemsCCM-SIP 811681 1 IN IP4 10.10.4.14 s=SIP Call c=IN IP4 10.10.10.40------>RTP sent directly to Xcoder t=0 0 m=audio 27770 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000--------------->G711Ulaw selected to use for the call a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 A show voip rtp connection shows the flow of RTP stream for the two call legs Show voip rtp conn on CUBE VoIP RTP active connections : No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP 1 175914 175915 17600 19092 10.10.4.174 10.10.10.10 (ITSP-->CUBE) 2 175915 175914 28214 29680 10.10.4.174 10.10.10.40 (CUBE--->Xcoder) Show sccp conn on transcoder sess_id conn_id stype mode codec sport rport ripaddr 536967492 537049324 xcode sendrecv g729ab 31246 16384 10.24.14.79 (region to xcoder =g729) 536967492 537049323 xcode sendrecv g711u 29680 28214 10.10.4.174 (reg to xcoder=G711)This is the device that invoked the xcoder Scenario 3, Call Flow ITSP--------sip----------->CUBE(1)--------sip----->CUCM---->IP Phone---CFWDall--->CUBE(2)----->ITSP (cubetoiphone=g729) (cubetocube=g729) SCENARIO 3------CALL FORWARDING Scenario 3, an inbound call comes to an IP phone via CUBE. The IP phone has a CFWdall set to a cell phone. Configurations: +++Voice-class codec++++ voice class codec 1 codec preference 1 g729r8 codec preference 2 g711ulaw codec preference 3 g711alaw ++++Inbound dial-peer to CUBE++++ dial-peer voice 1 voip modem passthrough nse codec g711ulaw incoming called-number . voice-class codec 1 dtmf-relay sip-kpml rtp-nte +++++Outbound dial-peer config to CUCM++++ dial-peer voice 50 voip description Inbound calls to CUCM translation-profile outgoing IN_PORT destination-pattern 44T modem passthrough nse codec g711ulaw session protocol sipv2 session target ipv4:10.10.4.74 session transport tcp dtmf-relay rtp-nte digit-drop h245-alphanumeric codec g711ulaw fax rate disable Region Settings between CUBE= G.729, region setting between cube and IP Phone=g729 CALL ANALYSIS 1. Call arrives on CUBE and matched DP=1 with voice-class codec set. 2. Call matches outbound dial-peer 50, codec set to G711ulaw 3. At this point regardless of the region setting between the ip phone and cube or sip trunk to the CUBE, G711u will be used. This is because the CUBE sends an early offer with only g711ulwa advertised. So CUCM is forced to send an ACK back with only g711u as the codec to use for the c all. 4. When the call arrived on ip phone, it was cfwdall to a cell, hence the call goes out via the same CUBE again (hairpinned) 5. Hence RTP connection is setup inbound to cube and outbound to cube. So in this case the second call leg of the call will be between CUBE-CUBE Now the region setting between CUBE-CUBE=G729. So we have a call flow like this: Callleg1=g711 Callleg2=G729 Hence a xcoder is needed. The CUBE invokes a xcoder. If there is no transcoder available, then this call will fail. Here is a trace for the call with only the relevant bits shown: Invite received from ITSP with early offer and SDP capabilities Received: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.106.33.24:5070;branch=z9hG4bKefn9r620a8p1h5dr1681.1 From: ;tag=286652269-1336598892064- To: "solihull-SPK TestGrid" Content-Type: application/sdp Content-Length: 207 v=0 o=BroadWorks 130097753 1 IN IP4 10.10.10.10 s=- c=IN IP4 10.10.10.10 t=0 0 m=audio 17652 RTP/AVP 18 0 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=fmtp:18 annexb=no Invite sent to CUCM with only G711u advertised Sent: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/TCP 10.10.4.20:5060;branch=z9hG4bK375566FA Remote-Party-ID: ;party=calling;screen=no;privacy=off From: ;tag=306F1686-1BE5 To: Date: Wed, 09 May 2012 21:28:12 GMT Call-ID: [email protected] Supported: timer,resource-priority,replaces,sdp-anat Min-SE: 1800 Cisco-Guid: 3066570383-2572423649-2537084334-1921242514 User-Agent: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp v=0 o=CiscoSystemsSIP-GW-UserAgent 8398 8261 IN IP4 10.10.4.20 s=SIP Call c=IN IP4 10.10.4.20 t=0 0 m=audio 29550 RTP/AVP 0 100 101 c=IN IP4 10.10.4.20 a=rtpmap:0 PCMU/8000-----------------G711Ulaw advertised a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 CUCM sends a 200 OK, agreeing on G711ulaw as the codec to use Received: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.10.4.20:5060;branch=z9hG4bK375566FA From: ;tag=306F1686-1BE5 To: ;tag=189823~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477054169 Date: Wed, 09 May 2012 21:28:12 GMT Call-ID: [email protected] CSeq: 101 INVITE Content-Type: application/sdp Content-Length: 214 v=0 o=CiscoSystemsCCM-SIP 189823 1 IN IP4 10.10.4.14 s=SIP Call c=IN IP4 10.10.10.40--------->CUCM informs CUBE to send RTP to Transcoder t=0 0 m=audio 17496 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000------------------>G711ulaw accepted a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 So on the first call leg G711ulaw is used Below is the Sh sccp connection on the Xcoder Tag13=ITSP--->CUBE call leg Tag14= CUBE--->Xcoder Call leg Sh voip rtp connection: 13 91498 91499 31298 23516 10.10.4.174 10.10.10.10 14 91499 91498 17432 25092 10.10.4.174 10.10.10.40 Observe that the region between the IP phone and the CUBE does not even come into play here. This is because the call was diverted, hence no RTP stream is sent to the phone.It is the destination where RTP stream will be sent to that codec negotiation will be considered for In this call setup, a xcoder at a remote site was used even though transcoder resources are configured on the CUBE and registered to CUCM. This is because the region setting between the Xcoder and the CUBE were wrongly configured. Hence the CUBE found an available transcoder in the default MRGL. This is a very crucial part of your design. Ensure that:The region setting between a XCODER and the Device invoking it is G711. sh sccp connections on the transcoder: NB: that the codec section has two main distinctions 1. The leg that invokes a xcoder will always be G711 2. The other leg of the call will use whatever region setting is configured between it and the xcoder. So if its G711, you will see G711, if its G729, you will see G729. sess_id conn_id stype mode codec sport rport ripaddr 536967470 469864467 xcode sendrecv g711u 32106 16882 10.10.4.174 536967470 469864466 xcode sendrecv g711u 25092 17432 10.10.4.174 We are seeing the CUBE ip here duplicated because this is a hairpinned call. The same CUBE is sending rtp connection to the xcoder. SCENARIO 4 Scenario 4 is similar to scenario 3 but the region settings are different and we use voice class codec on the outbound dial-peer to CUCM.An inbound call comes to an IP phone via CUBE. The Ip phone has a CFWdall set to a cell phone. ITSP------->CUBE--------->CUCM---->Ip Phone---CFWDall--->CUBE----->ITSP (cubetoiphone=g729) (cubetocube=g711) Configurations: +++Voice-class codec++++ voice class codec 1 codec preference 1 g729r8 codec preference 2 g711ulaw codec preference 3 g711alaw ++++Inbound dial-peer to CUBE++++ dial-peer voice 1 voip modem passthrough nse codec g711ulaw incoming called-number . voice-class codec 1 dtmf-relay sip-kpml rtp-nte +++++Outbound dial-peer config to CUCM+++++ dial-peer voice 50 voip description Inbound calls to CUCM translation-profile outgoing IN_PORT destination-pattern 44T modem passthrough nse codec g711ulaw session protocol sipv2 session target ipv4:10.10.4.74 session transport tcp dtmf-relay rtp-nte digit-drop h245-alphanumeric voice-class codec 1 fax rate disable Region Settings between CUBE(s)= G.711, region setting between cube(s) and IP Phone=g729 CALL ANALYSIS 1. Call arrives on CUBE and matched inbound DP=1 with voice-class codec set. 2. Call matches outbound dial-peer 50, voice-class codec set 3. When a voice-class is configured on a DP, the codec used will depend on the region setting between the source and the destination. Here, the source is cube (sip trunk), the destination is another cube (or the same cube depends on which cube cucm chose for the outbound leg of thecall (we have two cubes in our environment). The region setting between the CUBES is G711, hence the call will use G711 all the way. 4. RTP connection is setup inbound to cube and outbound to cube. So in this case both call legs will look like this Callleg1=g711---inbound call to cube Callleg2=G711..outbound calleg to cube from cube An abbreviated trace is shown below: Cube receives invite from ITSP with early offer and all supported codecs Received: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 10.106.33.24:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1 From: ;tag=451687893-1338998863036- To: " -SPK TestGrid" Content-Type: application/sdp v=0 o=BroadWorks 161384816 1 IN IP4 10.10.10.10 s=- c=IN IP4 10.10.10.10 t=0 0 m=audio 15382 RTP/AVP 18 0 8 101-------------Advertised CODECS a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=fmtp:18 annexb=no CUBE sends invite to cucm with early offer and codecs matched on voice-class code Sent: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F Remote-Party-ID: ;party=calling;screen=no;privacy=off From: ;tag=4C85AF62-DA1 To: User-Agent: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp Content-Disposition: session;handling=required v=0 o=CiscoSystemsSIP-GW-UserAgent 6494 4459 IN IP4 10.10.4.174 s=SIP Call c=IN IP4 10.10.4.174 t=0 0 m=audio 16668 RTP/AVP 18 0 8 100 101---------CUBE advertises Codec to CUCM c=IN IP4 10.10.4.174 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 After a couple of trying and ringing CUBE gets a 200 ok from cucm with endpoint codec and IP. Codec chosen based on the region between endpoint and CUBE sip trunk (CUBE-CUBE in this case) Received: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F From: ;tag=4C85AF62-DA1 To: ;tag=811681~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2- v=0 o=CiscoSystemsCCM-SIP 811681 1 IN IP4 10.10.4.14 s=SIP Call c=IN IP4 10.10.4.174------>RTP sent directly to CUBE (no xcoder involved) t=0 0 m=audio 27770 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000--------------->G711Ulaw selected to use for the call a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 In this call scenario we can see that no transcoder is involved because of the homogeneity of the codecs used. SCENARIO 5, Call Flow ITSP------------->CUBE---------->CUCM---->Ip Phone---CFWD--->UCXN (cubetoiphone=g729) (cubetocube=g711) SCENARIO 5------CALL FORWARDING TO Voice Mail (Xcoder Invoked) +++++=Calls forwarded to Unity connection from CUBE+++ using a xcoder Configurations: +++Voice-class codec++++ voice class codec 1 codec preference 1 g729r8 codec preference 2 g711ulaw codec preference 3 g711alaw ++++Inbound dial-peer to CUBE++++ dial-peer voice 1 voip modem passthrough nse codec g711ulaw incoming called-number . voice-class codec 1 dtmf-relay sip-kpml rtp-nte +++++Outbound dial-peer config to CUCM++++ dial-peer voice 50 voip description Inbound calls to CUCM translation-profile outgoing IN_PORT destination-pattern 44T modem passthrough nse codec g711ulaw session protocol sipv2 session target ipv4:10.10.4.74 session transport tcp dtmf-relay rtp-nte digit-drop h245-alphanumeric codec g711u fax rate disable CALL ANALYSIS 1. Call arrives on CUBE and matched DP=1 with voice-class codec set. 2. Call matches outbound dial-peer 50, codec set to G711ulaw 3. At this point regardless of the region setting between the ip phone and cube or sip trunk to the CUBE, G711u will be used. This is because the CUBE sends an early offer with only g711ulwa advertised. So CUCM is forced to send an ACK back with only g711u as the codec to use for the c all. 4. When the call arrived on ip phone, it was cfwd to voice mail, 5. Hence RTP connection is setup inbound to cube and outbound to unity connection. So in this case the second call leg of the call will be between CUBE->Unity connection Now the region setting between CUBE-Unity Connection=G729. So we have a call flow like this Callleg1=g711 Callleg2=G729 Hence a xcoder is needed. The CUBE invokes a xcoder. If there is no transcoder available, then this call will fail. show sccp connections on transcoder: sess_id conn_id stype mode codec sport rport ripaddr 536967470 469864467 xcode sendrecv g711u 32106 16882 10.10.4.70UCXN Server 536967470 469864466 xcode sendrecv g711u 25092 17432 10.10.4.174------CUBE Show voip rtp connection on CUBE 13 91498 91499 31298 23516 10.10.4.174 10.10.10.10 (ITSP->CUBE) 14 91499 91498 17432 25092 10.10.4.174 10.10.10.40 (CUBE->Xcoder) NB: This is a really bad design. You dont want calls to unity connection using a transcoder. This is happening because the codec and region configurations were poorly done without the consideration of how they interact. Now we have covered quite a few scenarios that are involved in our day to day call requirements on the inbound direction. Here is a quick recap In summary, rule on dial-peer and region settings is this When voice-class codec is used, the codec set on the region between the calling device and called device wil be used. E.g Cube calling ip phone and region set to G729, G729 will be used. If the same call is forwarded, then the ff: will happen If the region between the calling CUBE/Gateway, and the gateway used to make the Forwarded call is set to g729, then G729 will be used. If the region set between calling gateway and the gw making forwarded call = G711, then G711 will be used If the DP=G711 hard coded, and the region between the gateways is G729, then a xcoder will be invoked. as explained above If DP=g729 and region between gateways is G711, then g729 will be used (its as if G711 can step down to G729) Next lets look at Outbound Calls OUTBOUND CALLS IP phone----sccp----------->CUCM---------sip---------->CUBE--------sip----->ITSP In the outbound direction............... The advertised codec to ITSP will be used; because ITSP is the one making decision which codec to use based on advertised codec. So here with voice class codec, the preferred codec in the list will be selected by the ITSP and this will be used for the call regardless of what the region setting is on the phone to the cube gateway. If the codec is hardcoded, if its set to g711, then g711 response will be obtained from the ITSP and that codec will be used for the call. If its g729 then it will be g729. So the outbound leg is independent of the region settings because it is the far end that is choosing what codec to use for the call. It is important to understand this so that you know that the region setting will not determine what codec will be used for your outbound call leg. So if you want to choose a codec for your outbound leg, you have to either set it as preferred in your voice class list or hardcode it such that it is the codec been advertised as the preferred to your ITSP Configurations: +++Voice-class codec++++ voice class codec 1 codec preference 1 g729r8 codec preference 2 g711ulaw codec preference 3 g711alaw ++++Inbound dial-peer to CUBE++++ dial-peer voice 1 voip modem passthrough nse codec g711ulaw incoming called-number . voice-class codec 1 dtmf-relay sip-kpml rtp-nte +++++Outbound dial-peer config to ITSP++++ dial-peer voice 100 voip description Voice Calls To Verizon SIP Trunk translation-profile outgoing OUT_PORT destination-pattern .T session protocol sipv2 session target sip-server session transport udp voice-class codec 1 voice-class sip profiles 2 dtmf-relay rtp-nte digit-drop h245-alphanumeric fax rate disable ip qos dscp cs3 signaling no vad Abbreviated trace below: Invite sent to ITSP From CUBE Sent: From: "codec test" ;tag=4C8AB41A-1D46 To: Date: Wed, 06 Jun 2012 16:40:14 GMT Call-ID: [email protected] Supported: timer,resource-priority,replaces,sdp-anat Min-SE: 1800 Contact: v=0 o=CiscoSystemsSIP-GW-UserAgent 6874 7727 IN IP4 10.10.4.174 s=SIP Call c=IN IP4 10.10.4.174 t=0 0 m=audio 21956 RTP/AVP 18 0 8 100 101----Codecs advertised in the order preferred c=IN IP4 10.10.4.174 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 CUBE receives Session progress from ITSP NB that the provider is only sending G729 back. (based on the preferred codec in our list) Received: SIP/2.0 183 Session Progress v=0 o=BroadWorks 161411162 1 IN IP4 10.10.10.10 s=- c=IN IP4 10.10.10.10 t=0 0 m=audio 18758 RTP/AVP 18 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=fmtp:18 annexb=no CUBE sends 183 to CUCM with G729 Sent: SIP/2.0 183 Session Progress v=0 o=CiscoSystemsSIP-GW-UserAgent 2278 8254 IN IP4 10.10.4.174 s=SIP Call c=IN IP4 10.10.4.174 t=0 0 m=audio 29694 RTP/AVP 18 100 101 c=IN IP4 10.10.4.174 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 We received 200 ok from ITSP Received: SIP/2.0 200 OK v=0 o=BroadWorks 161411162 1 IN IP4 10.10.10.10 s=- c=IN IP4 10.10.10.10 t=0 0 m=audio 18758 RTP/AVP 18 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=fmtp:18 annexb=no CUBE sends 200 OK to CUCM with only G729 advertised sent: SIP/2.0 200 OK v=0 o=CiscoSystemsSIP-GW-UserAgent 2278 8254 IN IP4 10.10.4.174 s=SIP Call c=IN IP4 10.10.4.174 t=0 0 m=audio 29694 RTP/AVP 18 100 101 c=IN IP4 10.10.4.174 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 And the most important part cucm sends ACK with SDP with endpoint codec and IP NB: Even though the region between ip phone and Cube was set to G711, cucm sends ACK with G729. Received: ACK sip:[email protected]:5060 SIP/2.0 CSeq: 101 ACK Allow-Events: presence, kpml Content-Type: application/sdp v=0 o=CiscoSystemsCCM-SIP 812149 1 IN IP4 10.11.11.10 s=SIP Call c=IN IP4 10.50.17.20 t=0 0 m=audio 28170 RTP/AVP 18 101 a=rtpmap:18 G729/8000 a=ptime:20 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 SUMMARY/CONCLUSION Finally, Summarising both call scenario, In both cases the codec selected by the far end will determine what codec is used for the call. Inbound leg, far end is CUCM, region takes effect Outbound leg, far end is ITSP, prefered codec in advertised codec will take effect. Simples! Using Dummy SIP Trunk to get REFER based transfers working Using Dummy SIP Trunk to get REFER based transfers working In CUCM Versions below 9.X, we have a limitation of SIP Route Pattern not allowing us to point to a SIP Trunk that is already associated with a route group. This creates problems in call scenarios such as below : SCENARIO : [ Home-1 Cluster] User Calls 7777 --> CUSP ( via SIP Trunk CUSP1) --> CVP --> ICM (Script Runs, If no agents available = Kick out to 110011 = Hunt Pilot on Home-2 Cluster) --> CVP --> CUSP ( via SIP Trunk CUSP1) --> Home-2 Cluster Hunt Pilot 110011 [Fails] If we use a RE-INVITE method of performing a transfer, this scenario can be quite easy to achieve. However, at times customers would like to use the REFER mechanism for transfer. During such a scenario, CUCM has the capability of accepting the INBOUND REFER and handles this call based on the SIP Route Pattern configuration. In the above case, as an example this is what should happen ideally from signalling perspective : CUCMCUSP1 Trunk --INVITE--> Route List (RL-1) --> Route Group --> DEVICE 1: CUSP1 || DEVICE 2: CUSP2 Now to get the REFER transfer working for above call scenario, we will need CUSP1 to be configured under the SIP Route Pattern. Since it is associated to a route group, this configuration is a restriction on CUCM. The only workaround would be to point the SIP Route Pattern to RL-1( Route List), however this is a feature made possible on CUCM Versions 9 and above only. WORKAROUND : Configure an alternate SIP Trunk CUSPTEST that has the same destination IP Address as that of CUSP1. Since we cannot create two SIP Trunks with same destination IP Address, associate the new SIP Trunk with a SIP TRUNK SECURITY Profile "TEST_PROFILE" that has incoming port as any dummy port such as 5065. We don't need to bother about the dummy incoming port because CUSP is never going to talk to CUCM on that port for incoming messages. Once we have associated the new SIP Trunk CUSPTEST with the "TEST_PROFILE" we can now successfully associate this SIP Trunk to the SIP Route Pattern to get the above call flow working. This is a great example of how a dummy SIP Trunk can be used to get a simple REFER transfer working in such a deadlock situation. Hope this helps! Regards, Avinash Modifying the User Agent SIP Header with SIP Profiles Introduction This document explains "How to Add/Modify the User-Agent SIP header in the SIP Profiles ?" . Sometimes SIP header Modification is required in a Service provider network where the Device rejects an unknown header and expects optional header value or parameter. Problem description When we register the Cisco Router as SIP Gateway, the Provider will see the Router's Registered name as "User-Agent: Cisco-SIPGateway/IOS-12.x" in the SIP header. Is it possible to Rename the SIP User-Agent Name ? Sample SIP INVITE message with the User-Agent name ( field is highlighted in bold): *Mar 1 00:34:45.515: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received:BYE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.184.83:5060;branch=z9hG4bK1E1E51 From: ;tag=85E9C7C8-A4C To: ;tag=1EDC10-2436 Date: Tue, 28 Feb 2006 23:44:38 GMT Call-ID: [email protected] User-Agent: Cisco-SIPGateway/IOS-12.x Max-Forwards: 70 Timestamp: 1141170279 CSeq: 103 BYE Reason: Q.850;cause=16 Content-Length: 0 *Mar 1 00:34:45.535: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent:SIP/2.0 200 OK Via: SIP/2.0/UDP 172.16.184.83:5060;branch=z9hG4bK1E1E51 From: ;tag=85E9C7C8-A4C To: ;tag=1EDC10-2436 Date: Fri, 01 Mar 2002 00:34:45 GMT Call-ID: [email protected] Server: Cisco-SIPGateway/IOS-12.x Timestamp: 1141170279 CSeq: 103 BYE Reason: Q.850;cause=16 Content-Length: 0 Solution

Yes, It is possible to Rename the default SIP User-Agent name by Modifying the User Agent in SIP Header using Sip profile. Configuration To Modify the User Agent SIP header The following configuration modifies the User Agent - SIP header Cisco-SIPGateway/IOS-12.x to Cisco-SIP-Gateway Message: INVITE Action: Modify the User-Agent SIP header Rules: voice class sip-profiles 100 request INVITE sip-header User-Agent modify Cisco-SIPGateway/IOS-12.x Cisco-SIP-Gateway Configuration Setps voice service voip media flow-around allow-connections sip to sip sip sip-profiles 100 voice class sip-profiles 100 request INVITE sip-header User-Agent modify Cisco-SIPGateway/IOS-12.x Cisco-SIP-Gateway Configuration To Add the User Agent SIP header The following configuration Adds the User Agent SIP header User-Agent: CiscoSystems-SIP-GW-UA" Message: 200 Response Action: Add the User-Agent SIP header Rules: voice class sip-profiles 100 response 200 sip-header User-Agent add "User-Agent: CiscoSystems-SIP-GW-UA" Configuration Steps voice service voip media flow-around allow-connections sip to sip sip sip-profiles 100 voice class sip-profiles 100 response 200 sip-header User-Agent add "User-Agent: CiscoSystems-SIP-GW-UA"


Sip Trunk Cucm

CUPS with CUCM

Cucm Health

IC 4.0 SIP INTEGRATION TO - Interactive Intelligencetestlab.inin.com/compatibilityfiles_external/documents/CUCM8_SIP... · call from pstn to cucm station -transfer from phone

Oracle Enterprise Session Border Controller and CUCM · PDF fileOracle Enterprise Session Border Controller and CUCM 11.0 with Telus Enterprise SIP Trunk Technical Application Note

Configuring MP-1288 SIP Gateway in Cisco Unified ... · Analog Gateway in Cisco Unified Communications Manager Ver. 10 ... Unified Communications Manager (CUCM) ... Communications

SIP Trunking using CUCM and - alcatron.net Live 2013 Melbourne/Cisco Live... · ‒SIP Trunk Codec Support – Audio Codec Preference Lists ‒SIP Trunk Security ‒QSIG Over SIP

Verizon SIP Trunking Configuration Guide - CUCM … · and session control services for Cisco Unified Communications Manager 10.5.2 connected to Verizon IP network. ... (number) Identification

CUCM 10.5 / CUBE 9 - Virgin Media Business...CUCM 10.5 / CUBE 9.5 BT SIP Trunk Configuration Guide This document covers service specific configuration required for interoperability

CUCM BK CA32DEF9 00 Cucm User Options Guide 90

Cups Integrate Cucm

(CUCM) Version 11.0.1.21900-11 ommunications Manager · PDF fileC SIP Trunking Configuration Guide for Cisco Unified ommunications Manager (CUCM) Version 11.0.1.21900-11 with Cisco

Cucm Ipo Siptrk

XO SIP Service - XO Communications€¦ · XO SIP Service Customer Configuration Guide for Cisco Unified Communications Manager (CUCM) 7.0.1 XO SIP Packages 1 and 2, implemented without

Ascom CUCM IVT Report 2 - ascom-ws.com · DevNet web site: ... Integrates to CUCM with SIP, to provide a feature-rich telephony solution

CUCM BK CEF0C471 00 Cucm-features-And-services-guide Chapter 01110

Spectrum Enterprise SIP Trunking: CUCM 11.5.1 with CUBE 11 ... · Unified Border Element provides demarcation, security, interworking and session control services for Cisco Unified

BT Cloud CUCM. · BT Cloud CUCM. Video, delivered as a service. Data sheet. Minimise your video-conferencing costs with BT Cloud CUCM. BT Cloud CUCM (Cisco Unified Communications

Business Talk BTIP Guide Cisco CUCM · - If more than 1 Subscriber, the SIP trunks are held by the Subscribers. The Publisher holds the database. Subscriber1 IP@ Subscriber2 IP@ CUCM

(CUCM) Version 10.5.1.10000 ommunications … Cisco Unified Border Element (CUBE) SIP Trunking Configuration Guide for Cisco Unified Communication Manager with CUBE ... CUBE software,

Sprint SIP Trunking - CUCM 11.5.1 with CUBE 12.0.0 on ISR

SIP Trunking Configuration Guide for Cisco Unified ... Trunking Configuration Guide for Cisco Unified Communications Manager (CUCM) Version 9.0.1.11005-1 with Cisco Unified Border

Pexip Infinity and Cisco UCM Deployment Guide · CUCM version 9.x includes a preconfigured SIP profile — Standard SIP Profile For Cisco VCS — which you can use for Pexip Infinity

RATING ROADMAP BUCR - CUCM · PDF file30.05.2012 · 1 bucr - cucm rating roadmap bucr - cucm rating road map may 2012

EarthLink Business SIP Trunking - Windstream Enterprise...Cisco CUCM & CUBE Open Issues & Non-Supported Features SIP Refer message enhancements were not added to CUCM until 8.6 Cisco

Nexmo SIP Trunking Configuration Guide CUCM · PDF fileThis configuration guide provides steps for configuring Cisco Unified Communications Manager (Cisco UCM) 11.5.1.12900-21 and

Oracle Enterprise Session Border Controller and CUCM 10.5 ... · The sip-feature 100rel is added to the config for SIP PRACK interworking, ... last-modified-by [email protected]

G12 Communications SIP Trunking - Connecting CUCM 11.5.1 … · G12 Communications SIP Trunking: Cisco Unified Communications Manager 11.5.1 ... IOS 15.4(3)M1 for Cisco 2921 Fax Gateway

CUCM SIP Trunking Configuration - Cox Communicationsmedia.cox.com/cbsupport/print_media/phone/equipmen… ·  · 2012-01-13PROPRIETARY & CONFIDENTIAL Figure 20 - SIP Trunk Security

CUCM BK CF3D71B4 00 Cucm Virtual Servers

vCUSP Webinar Slides - Cisco · •SIP trunk aggregation CUCM,CUCME,SP trunk, CVP •Flexible routing and normalization policies qCUSP offers the following benefits • Simplified

IntelePeer for Cisco SIP Trunking - CUCM Configuration Guide

CUCM Traces

CUCM BK I05CD008 00 Installing-cucm-91

Cisco TelePresence Cisco Unified Communications Manager ... · Cisco TelePresence Cisco Unified Communications Manager with Cisco VCS (SIP Trunk) Deployment Guide Cisco VCS X8.1 CUCM