- Introduction
- CUCM Routing Rules
- Dial String implementation Policy
- CUCM Routing Logic
- SIP URI Call Routing Analysis
- +++ Case Study: 1 +++
- +++ Case Study: 2 +++
- Conclusion
Introduction
Over the last few months, I have had the privilege of working on SIP URI dialing solutions. This has become an intricate part of the UC collaboration architecture and an in-depth understanding is essential in designing, deploying and troubleshooting the solution. As SIP becomes the de facto protocol used in collaboration, SIP URI dialing becomes more entwined within our day to day usage of the technology.
I must acknowledge that there are some excellent documentations that have been written on this subject and I will be referencing one of them here. However, I have observed that there are still little intricacies that need to be understood in other to correctly deploy SIP URI dialing within an enterprise and I am referring particularly to CUCM's routing logic for SIP URI dialing. In this document I will be focusing on of these little details with real life examples. So get a cup of coffee and join me on this ride..
NB: To get the best of of this document, you should ensure you have a good understanding or SIP URI dialing. You can refer to this excellent document here.
https://supportforums.cisco.com/t5/collaboration-voice-and-video/sip-uri-dialing/ta-p/3157406
CUCM Routing Rules
Dial String implementation Policy
One of the most critical piece in determining how CUCM routes a call is the dial string implementation policy. This setting defined under CUCM SIP profile informs CUCM how to treat the Request URI. Why is this important? The answer is very simple. CUCM uses a set of logic to determine how to route a call either based on number URI or directory URI. The logic is similar but different in both cases. Having established that, it is imperative for CUCM to know if the RURI is a number URI or a directory URI. To do this CUCM uses the dial string implementation policy. The sample screen shot below shows that the dial string implementation policy looks like on a sip profile
CUCM Routing Logic
Having established the first point above, lets now look at the logic CUCM uses to route calls. The diagram below shows the logic that CUCM applies in routing call based on the deterministic outcome of its dial string implementation policy.
SIP URI Call Routing Analysis
If you have had the pleasure of reading some of my documents, you must have observed that I take a very practical and detailed approach to my writings. Its just the way my brain works. I need to see how it works and then it sticks ( Maybe because I don't have a very high IQ :))
So lets dive in and tie all these together
+++ Case Study: 1 +++
|
dial string implementation policy: |
Phone number consists of characters 0–9, A–D, *, #, and + (others treated as URI addresses) |
In case study 1: We will look at scenarios with the dial string implementation policy set as above and observe how CUCM analyses the call before it is routed.
<<< Example 1a: >>>
- Roue Pattern and SIP Route Pattern
Below are the details of the call for our first example.
|
Dialed number = *697369990
CSS contains: PT-Direct-US---------> Matches RP=*xxxxxxxx |
|
++ CUCM DA +++
Because of dial string implementation policy, CUCM considers the dialed number as numeric and here is CUCM DA process. 42233805.002 |06:32:38.516 |AppInfo |Digit Analysis: Host Address=corp.services.com DOES NOT MATCH any active CUCM node in this cluster. 42233805.003 |06:32:38.516 |AppInfo |Digit Analysis: Host Address=corp.services.com MATCHES top level org domain. 42233805.004 |06:32:38.516 |AppInfo |Digit Analysis: star_DaReq: Matching SIP URL, Numeric User, user=*697369990 42233805.005 |06:32:38.517 |AppInfo |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0] 42233805.006 |06:32:38.517 |AppInfo |Digit Analysis: getDaRes - Remote Destination [*697369990] isURI[0] 42233805.007 |06:32:38.517 |AppInfo |CMUtility routeCallThroughCTIRD: no matching RemDestDynamic record exists for remdest [*697369990] 42233805.008 |06:32:38.517 |AppInfo |DbMobility: getMatchedRemDest starts: cnumber = *697369990 42233805.009 |06:32:38.517 |AppInfo |DbMobility: getMatchedRemDest: partial match 42233805.010 |06:32:38.517 |AppInfo |DbMobility: getMatchedRemDest: number to partial match is *697369990 42233805.011 |06:32:38.517 |AppInfo |DbMobility: getMatchedRemDest: need to match 10 digits 42233805.012 |06:32:38.517 |AppInfo |DbMobility: getMatchedRemDest can't find remdest *697369990 in map 42233805.013 |06:32:38.517 |AppInfo |Digit analysis: patternUsage=5 42233805.014 |06:32:38.517 |AppInfo |Digit analysis: match(pi="2", fqcn="+17692629998", cn="+17692629998",plv="5",
+++ Next CUCM considers how to route the number +++ You can use the CUCM routing logic diagram to see how this iterations are done.
1. If the RHS matched CFQD ( this call belongs to this cluster), analyze LHS ( ie is there a DN/Translation Pattern/RP/ILS-GDPR Pattern matched, If not Block the call). This will keep the call LOCAL. If the RHS does not match the CFQD, then do step 2 below. ( in this example we can see that the RHS does not match the CFQD, so CUCM moves to step 2)
2. Does the RHS matches a top level organization level domain ( The call may belong to this cluster or an organization that we know). If it does then do the following
++ When CSS contains both Route Pattern and SIP Route Pattern ++ In example above, the CSS on this Telepresence endpoint contains PT that matches both a route pattern ans a SIP route pattern as shown int he call detail above
Since there is a RP matched for *XXXXXXXXX in PT-Direct-US
Step (2a) above is matched, hence call is routed to the RL the RP *XXXXXXXXX is pointing to.
The DA process shows this.
|
<<< Example 1b >>>
- SIP Route Pattern only
Now lets consider a case where the CSS on the device only matches a SIP route pattern.
|
When the CSS on TP device is = CSS-DEV-US = PT-Offnet
|
Summary and Notes:
Once CUCM determines that the dial string is Numeric and only the OTLD is matched the following rule applies
- Route Patterns takes precedence over SIP route pattern
- SIP Route pattern will be used if no Route Pattern is matched
<<<<<< Example 1c: >>>>>>>>
- Directory-URI not matched in ILS network
- In this example, a TP endpoint was configured with a directory URI of +442037703476@corp.services.com.
- Another video endpoint tried to call this endpoint, however calls were being routed out via PSTN rather than ILS network
++++ INVITE sip:+442037703476@corp.services.com SIP/2.0 ++++
CUCM treats the dialed address as a number and hence follows the numeric call routing logic described above. In this case the pattern was matched to a Route Pattern for PSTN can video calls were going over PSTN which meant loss of video.
| 96627980.002 |01:03:27.767 |AppInfo |Digit Analysis: Host Address=corp.services.com DOES NOT MATCH any active CUCM node in this cluster. 96627980.003 |01:03:27.767 |AppInfo |Digit Analysis: Host Address=corp.services.com MATCHES top level org domain. 96627980.004 |01:03:27.767 |AppInfo |Digit Analysis: star_DaReq: Matching SIP URL, Numeric User, user=+442037703476 96627980.005 |01:03:27.768 |AppInfo |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0] 96627980.006 |01:03:27.768 |AppInfo |Digit Analysis: getDaRes - Remote Destination [+442037703476] isURI[0] --- --- 96627980.015 |01:03:27.768 |AppInfo |Digit analysis: analysis results 96627980.016 |01:03:27.768 |AppInfo ||PretransformCallingPartyNumber=+914019994512 |CallingPartyNumber=+914019994512 |DialingPartition=PT-PSTN |DialingPattern=+.! |FullyQualifiedCalledPartyNumber=+442037703476 |DialingPatternRegularExpression=(+)([0-9]+) --- |TranslationPatternDetails= |PretransformCallingPartyNumber=+914019994512 |CallingPartyNumber=+914019994512 |DialingPartition=PT-OffNet |DialingPattern=\+[2-9]! |FullyQualifiedCalledPartyNumber=+442037703476 |DialingPatternRegularExpression=(+[2-9][0-9]+) |DialingWhere= |
Question/Summary: Why did CUCM not match the Directory URI for the called endpoint in ILS network? The simple answer is:
Once CUCM determines that the dial string is a number, then CUCM CUCM doesn’t use "any Directory URI ( even with numbers) advertised by ILS to find the call e.g. +442037703476@corp.services.com will not be matched when +44789654333 is dialed ( This point is very important especially in CUCM clusters with telepresence endpoints. If directory URI(s) are configured using number patterns you will not be able to route them over ILS unless you change your dial string implementation policy.
<<< Example 2: >>>
- ILS-Directory URI Matched Pattern
So far we have considered examples with number URIs. Now lets look at directory URI
The example below shows CUCM routing when a directory URI is dialed.
| RURI: INVITE sip:pikeisland@corp.services.com SIP/2.0 |
The RURI is interpreted as a directory URI and follows URI call routing logic +++
In this example the directory URI was matched to an ILS pattern and the call was routed using the SIP route string that was associated to the advertised pattern in ILS
|
43906919.002 |20:51:56.677 |AppInfo |Digit Analysis: Host Address=corp.services.com DOES NOT MATCH any active CUCM node in this cluster. |
<<< Example 3 >>>
- ILS-GDPR number URI Matched Pattern
| Dialed +17792621052, INVITE sent to CUCM from TP endpoint INVITE sip:+17792621052@corp.services.com SIP/2.0 |
CUCM interpreted dialed number as Numeric
| 37801960.002 |15:53:52.426 |AppInfo |Digit Analysis: Host Address=corp.services.com DOES NOT MATCH any active CUCM node in this cluster. 37801960.003 |15:53:52.426 |AppInfo |Digit Analysis: Host Address=corp.services.com MATCHES top level org domain. 37801960.004 |15:53:52.426 |AppInfo |Digit Analysis: star_DaReq: Matching SIP URL, Numeric User, user=+17792621052 37801960.005 |15:53:52.426 |AppInfo |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0] 37801960.006 |15:53:52.426 |AppInfo |Digit Analysis: getDaRes - Remote Destination [] isURI[1] |
+++ Because the RHS matches OLTD, CUCM evaluates LHS as follows:
- Did we match a Route Pattern: NO,
- Did we match a translation pattern: No
Did we match an ILS-GDPR pattern: YES
| 37801960.007 |15:53:52.426 |AppInfo |Digit analysis: patternUsage=26 37801960.008 |15:53:52.426 |AppInfo |Digit analysis: match to an ILS learned route, ILSPattern=Global Learned E164 Patterns, routeString=us.corp.services.com --- ++ DA +++ 37801960.010 |15:53:52.427 |AppInfo |Digit analysis: analysis results 37801960.011 |15:53:52.427 |AppInfo ||PretransformCallingPartyNumber=+914019994512 |CallingPartyNumber=+914019994512 |DialingPartition=Global Learned E164 Patterns |DialingPattern=+1779262[1-3]XXX |FullyQualifiedCalledPartyNumber=+17792621052 |DialingPatternRegularExpression=(+1779262[1-3][0-9][0-9][0-9]) -- --- |AlternateMatches= { |Partition=PT-OffNet { < |Pattern=\+1XXXXXXXXXX |PatternType=Translation ----- 37801961.003 |15:53:52.427 |AppInfo |SMDMSharedData::findLocalDevice - Name=ILS-US-SIP-TRUNK Key=2050eb55-7b9a-a2ff-0e29-e9a11a488037 isActvie=1 Pid=(2,82,3) found |
Summary and Notes:
Once CUCM determines that the dial string is Numeric the following rule applies (
- CUCM uses the Numeric logic routing rule
- Route Patterns takes precedence over SIP route pattern ( if CFQDN or OTLD is matched)
- CUCM will only use GDPR patterns advertised over ILS ( if CFQDN or OTLD is matched)
- CUCM will not match a directory URI advertised in ILS. ( if CFQDN or OTLD is matched)
- CUCM uses SIP route patterns when CFQDN or OTLD does not match
<<< Example 4:>>>
- Numeric URI and CFQDN
In this example, lets consider what happens when CFQDN is matched and the dial string is interpreted as numeric.
| INVITE sip:699403702@services-cmr.webex.com SIP/2.0 29541009.002 |03:02:15.985 |AppInfo |Digit Analysis: Host Address=services-cmr.webex.com MATCHES Cluster FQDN. 29541009.003 |03:02:15.985 |AppInfo |Digit Analysis: star_DaReq: Matching SIP URL, Numeric User, user=699403702 29541009.004 |03:02:15.985 |AppInfo |Digit Analysis: Host Address=services-cmr.webex.com DOES NOT MATCH top level org domain. 29541009.005 |03:02:15.985 |AppInfo |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0] 29541009.006 |03:02:15.985 |AppInfo |Digit Analysis: getDaRes - Remote Destination [] isURI[1] |
++ Because CFQDN was matched, CUCM always route using the LHS on the local cluster. In this case the pattern 699403702 was not found, hence CUCM returns no match found as seen below
| 29541009.009 |03:02:15.985 |AppInfo |Digit analysis: potentialMatches=NoPotentialMatchesExist |
Summary/Notes
- When CFQDN is matched, and the dial string is interpreted as Numeric, CUCM will always use the LHS to route the call. A SIP route pattern will never be considered
+++ Case Study: 2 +++
+++ When the dial string policy was set to treat all addresses as URI ++++
|
dial string implementation policy: |
Always treat all dial strings as URI addresses |
<<< Example 1:>>>
- ILS-Routed Directory-URI
In this example, the following number was dialed
+17475533507
INVITE sent to CUCM from TP endpoint
+++ INVITE sip:+17475533507@corp.services.com SIP/2.0 +++
Based on the dial string implementation policy, CUCM interprets the dialed number as a directory URI. CUCM then applies the following routing logic.
- Is this a Local URI? ( Ie Can I find this in my cluster): In this case No
- Can I find this URI in ILS: In this case Yes
CUCM then routes this call using Learned pattern in ILS.
Here is snapshot of the CUCM trace
|
45491076.002 |04:04:22.580 |AppInfo |Digit Analysis: Host Address=corp.services.com DOES NOT MATCH any active CUCM node in this cluster. |
<<< Example 2a: >>>
- SIP Route Pattern-Routed Directory URI ( CFQDN and OTLD are not matched)
In this example, the following number was dialed
|
*699735780 Invite sent to CUCM from endpoint |
Based on the dial string implementation policy, CUCM interprets the dialed number as a directory URI. CUCM then applies the following routing logic.
- Is this a Local URI? ( Ie Can I find this in my cluster): In this case No
- Can I find this URI in ILS: In this case No
- Does this match a SIP Route Pattern: Yes
CUCM then routes this call using the pre configured SIP route pattern ("*.com")
Here is snapshot of the CUCM trace
|
45497998.002 |04:06:39.700 |AppInfo |Digit Analysis: Host Address=services-cmr.webex.com DOES NOT MATCH any active CUCM node in this cluster.
+++ CUCM doesn't find the dialed string in ILS, hence uses SIP route pattern. NB: That in DA, CUCM doesnt show which dialing pattern is matched for this. This is normal for URI based pattern matched to SIP Route pattern +++
|
<<< Example 2b: >>>
- SIP Route Pattern-Routed Directory URI ( CFQDN matched)
In this example, the following number was dialed
|
*699735780 Invite sent to CUCM from endpoint |
The CFQD was matched in this case.
| 29683189.002 |03:17:58.672 |AppInfo |Digit Analysis: Host Address=services-cmr.webex.com MATCHES Cluster FQDN. 29683189.003 |03:17:58.672 |AppInfo |Digit Analysis: star_DaReq: Matching SIP URL, Alphaumeric User, uri=699403702@services-cmr.webex.com 29683189.004 |03:17:58.674 |AppInfo |Digit Analysis: star_DaReq: IMDB lookup failed 29683189.005 |03:17:58.674 |AppInfo |star_DaReq: Attempt Match on Route String Host: services-cmr.webex.com --- 29683189.010 |03:17:58.674 |AppInfo |Digit Analysis: getDaRes - Remote Destination [699403702@services-cmr.webex.com] isURI[1] -- 29683189.018 |03:17:58.675 |AppInfo |Digit analysis: analysis results 29683189.019 |03:17:58.675 |AppInfo ||PretransformCallingPartyNumber=+17984507349 |CallingPartyNumber=+17984507349 |DialingPartition= |DialingPattern= |FullyQualifiedCalledPartyNumber= |DialingPatternRegularExpression= |DialingWhere= |PatternType=Unknown |PotentialMatches=NoPotentialMatchesExist |DialingSdlProcessId=(0,0,0) |PretransformDigitString=moc.xebew.rmc-secivres@207304595 -- |CallableEndPointName=[c6878789-56da-ec98-358a-067a35a71e6f] -- 29683191.003 |03:17:58.675 |AppInfo |SMDMSharedData::findLocalDevice - Name=VCSC-SIP-TRUNK Key=c6878789-56da-ec98-358a-067a35a71e6f isActvie=1 Pid=(6,84,59) found |
Summary/Notes
- When dial string is interpreted as a URI, the CFQDN and OTLD dont play any role in call routing. Call routing logic is the same all the time. I.E.
- 1. check local cluster
- 2. check ILS
- 3. use SIP route pattern
- Finally when the dial string is interpreted as a URI, CUCM doesn't route based on the LHS. It routes using the whole URI even when the CFQDN is matched.
<<< Example 3: >>>
- Number interpreted as URI
In this example, the following number was dialed
|
+447966427386 Invite sent to CUCM from endpoint |
++ Because of dial string implementation policy, CUCM interprets the dialed number as a URI +++
It then follows the URI routing logic: It checks the URI in local cluster, tries to look it up in ILS, but didn’t find it and then route it using a SIP route pattern. The problem with this is that this call should be going out via a local gateway, but its now been routed via VCS.
| 37336002.002 |13:33:20.670 |AppInfo |Digit Analysis: Host Address=corp.services.com DOES NOT MATCH any active CUCM node in this cluster. 37336002.003 |13:33:20.670 |AppInfo |Digit Analysis: Host Address=corp.services.com MATCHES top level org domain. 37336002.004 |13:33:20.670 |AppInfo |Digit Analysis: star_DaReq: Matching SIP URL, Alphaumeric User, uri=+447999437386@corp.services.com 37336002.005 |13:33:20.675 |AppInfo |Digit Analysis: star_DaReq: IMDB lookup failed 37336002.006 |13:33:20.675 |AppInfo |star_DaReq: Attempt Match on Route String Host: corp.services.com -- 37336002.019 |13:33:20.676 |AppInfo |Digit analysis: analysis results 37336002.020 |13:33:20.676 |AppInfo ||PretransformCallingPartyNumber=+914019994512 |CallingPartyNumber=+914019994512 |DialingPartition= |DialingPattern= |FullyQualifiedCalledPartyNumber= |DialingPatternRegularExpression= |DialingWhere= |PatternType=Unknown |PotentialMatches=NoPotentialMatchesExist |DialingSdlProcessId=(0,0,0) |PretransformDigitString=moc.secivres.proc@683314999744+ -- 37336003.003 |13:33:20.676 |AppInfo |SMDMSharedData::findLocalDevice - Name=VCS-SIP-TRUNK Key=cf42e10c-ff8a-af2d-e3bf-b984d4c9a1ef isActvie=1 Pid=(2,82,69) found |
Summary/Notes: Your dial string implementation policy plays a massive role in SIP URI dialing. Consider carefully how this is implemented and under the role it plays in your dial plan
Conclusion
My goal each time, I write a document is to help bring you the collaboration engineer closer to the particular technology under discussion. To help give you a leverage on your job, at an interview and to champion the Cisco cause.
I hope I have achieved this in this short write up. Do leave me a feed back and dont forget to hit the stars. Adieu!
