cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
14046
Views
105
Helpful
7
Comments
Ayodeji Okanlawon
VIP Alumni
VIP Alumni

 

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

dialstring.JPG

 

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.

 

logicpicture.png

 

 

 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
Sip endpoint prefix its domain, hence INVITE sent to CUCM =
INVITE sip:*697369990@corp.services.com SIP/2.0

 

CSS contains: PT-Direct-US---------> Matches RP=*xxxxxxxx
CSS contains: PT-Offnet--------> Matches SIP RP= *services.com

 

 

 

++ 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

  •  a . Analyze the LHS ( ie is there a DN/Translation Pattern/RP/ILS-GDPR Pattern matched) If there is route based on the pattern matched. If not do (b)
  • b. Does the RHS finds a SIP route Pattern, if Yes Route or block

++ 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.

++ DA +++
42233805.015 |06:32:38.517 |AppInfo  |Digit analysis: analysis results
42233805.016 |06:32:38.517 |AppInfo  ||PretransformCallingPartyNumber=+17692629998
|CallingPartyNumber=+17692629998
|DialingPartition=PT-Direct-US
|DialingPattern=*XXXXXXXXX
|FullyQualifiedCalledPartyNumber=*697369990
|DialingPatternRegularExpression=(*[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9])
--
42233807.003 |06:32:38.517 |AppInfo  |SMDMSharedData::findLocalDevice - Name=RL-VCS-US Key=4e738caf-d555-76b2-0804-53b2eb351f76 isActvie=1 Pid=(6,90,33) found

 

<<< 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
and there is a SIP route Pattern (*services.com in PT-Offnet)


step (2b) above is matched and call is routed using SIP route Pattern

+++ DA +++

INVITE sip:*794299756@corp.services.com SIP/2.0

+++ CUCM considers the dialled number as Numeric  based on the dialed string implementation policy+++

005322411.002 |14:47:17.577 |AppInfo  |Digit Analysis: Host Address=corp.services.com DOES NOT MATCH any active CUCM node in this cluster.
05322411.003 |14:47:17.577 |AppInfo  |Digit Analysis: Host Address=corp.services.com MATCHES top level org domain.
05322411.004 |14:47:17.577 |AppInfo  |Digit Analysis: star_DaReq: Matching SIP URL, Numeric User, user=*794299756
05322411.005 |14:47:17.577 |AppInfo  |Digit Analysis: Host Address=corp.services.com MATCHES top level org domain.
05322411.006 |14:47:17.577 |AppInfo  |Digit Analysis: star_DaReq: Matching SIP URL, Host Domain, host=moc.secivres.proc
05322411.007 |14:47:17.577 |AppInfo  |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0]

+++ However because a SIP route pattern was matched, CUCM then says the dialed numeric number is a URI  ( this is different from the dial string implementation policy analysis. This is now based on the matched pattern ++++

05322411.008 |14:47:17.577 |AppInfo  |Digit Analysis: getDaRes - Remote Destination [*794299756@corp.services.com] isURI[1]
05322411.009 |14:47:17.577 |AppInfo  |CMUtility routeCallThroughCTIRD: no matching RemDestDynamic record exists for remdest [*794299756@corp.services.com]
05322411.010 |14:47:17.577 |AppInfo  |DbMobility: getMatchedRemDest starts: cnumber = *794299756@corp.service-now.comURI:PT-OnNet-Global:Directory URI:PT-OffNet", dd="*794299756",dac="1")
05322411.016 |14:47:17.577 |AppInfo  |Digit analysis: analysis results
05322411.017 |14:47:17.577 |AppInfo  ||PretransformCallingPartyNumber=+17213099789
|CallingPartyNumber=+17213099789
|DialingPartition=PT-OffNet
|DialingPattern=([mM][oO][cC].[sS][eE][cC][iI][vV][rR][eE][sS][\-.a-zA-Z0-9]?)

 

 

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.
43906919.003 |20:51:56.677 |AppInfo  |Digit Analysis: Host Address=corp.services.com MATCHES top level org domain.
43906919.004 |20:51:56.677 |AppInfo  |Digit Analysis: star_DaReq: Matching SIP URL, Alphaumeric User, uri=pikeisland@corp.services.com
43906919.005 |20:51:56.681 |AppInfo  |CcmCcmdbHelper::getRouteStringGivenURI match_row.pattern_m =pikeisland@corp.services.com
43906919.006 |20:51:56.681 |AppInfo  |Digit Analysis: star_DaReq: Matched URI in remoteroutingpattern table. uri = pikeisland@corp.services.com, routeString=us.corp.services.com
43906919.007 |20:51:56.681 |AppInfo  |star_DaReq: Attempt Match on Route String Host: us.corp.services.com

 

<<< 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.
45491076.003 |04:04:22.580 |AppInfo  |Digit Analysis: Host Address=corp.services.com MATCHES top level org domain.
45491076.004 |04:04:22.580 |AppInfo  |Digit Analysis: star_DaReq: Matching SIP URL, Alphaumeric User, uri=+17475533507@corp.services.com
45491076.005 |04:04:22.587 |AppInfo  |CcmCcmdbHelper::getRouteStringGivenURI match_row.pattern_m =+17475533507@corp.services.com
45491076.006 |04:04:22.587 |AppInfo  |Digit Analysis: star_DaReq: Matched URI in remoteroutingpattern table. uri = +17475533507@corp.services.com, routeString=us.corp.services.com
45491076.007 |04:04:22.587 |AppInfo  |star_DaReq: Attempt Match on Route String Host: us.corp.services.com
45491076.008 |04:04:22.587 |AppInfo  |star_DaReq: new ils callableEnpoint 2050eb55-7b9a-a2ff-0e29-e9a11a488037

 

<<< 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
+++ INVITE sip:*699735780@services-cmr.webex.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 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.
45497998.003 |04:06:39.700 |AppInfo  |Digit Analysis: Host Address=services-cmr.webex.com DOES NOT MATCH top level org domain.
45497998.004 |04:06:39.700 |AppInfo  |Digit Analysis: star_DaReq: Matching SIP URL, Alphaumeric User, uri=*699735780@services-cmr.webex.com
45497998.005 |04:06:39.705 |AppInfo  |Digit Analysis: star_DaReq: IMDB lookup failed-----ILS lookup failed
45497998.006 |04:06:39.705 |AppInfo  |star_DaReq: Attempt Match on Route String Host: services-cmr.webex.com-------CUCM tries to find a route string in ILS that matches this.

 

+++ 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 +++

45497998.019 |04:06:39.706 |AppInfo  |Digit analysis: analysis results
45497998.020 |04:06:39.706 |AppInfo  ||PretransformCallingPartyNumber=+914019994512
|CallingPartyNumber=+914019994512
|DialingPartition=
|DialingPattern=
|FullyQualifiedCalledPartyNumber=
|DialingPatternRegularExpression=
|DialingWhere=
|PatternType=Unknown
|PotentialMatches=NoPotentialMatchesExist
|DialingSdlProcessId=(0,0,0)
|PretransformDigitString=moc.xebew.rmc-secivres@087537996*

45497999.003 |04:06:39.706 |AppInfo  |SMDMSharedData::findLocalDevice - Name=RL-HKG-VCSC Key=c3f73dca-0f4a-c316-0fc4-53fb6809dfe8 isActvie=1 Pid=(2,90,45) found

 

 

 

<<< 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
INVITE sip:699403702@servicenow-cmr.webex.com SIP/2.0

 

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
INVITE sip:++447999437386@corp.services.com SIP/2.0

 

++ 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!

Comments
aalejo
Level 5
Level 5

Hey Ayodeji

Nice document you have created! :)

What about if URI LHS is a number but it was learned by ILS?  On the image, it is explained ILS routing when URI LHS is an alpha but no when LHS is numeric

 

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

HI Alex (From memory I think your name is alex, but pardon me if I am wrong)

Example 3 explained this scenario:

<<< Example 3 >>>

  • ILS-GDPR number URI Matched Pattern

In this case call will be routed as follows:

+++ 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

Then we will route the call based on the sip route pattern matched to the route string attached to the pattern

aalejo
Level 5
Level 5

Yes, that's me! Long time no see.

 

Correct me if i am wrong, on example 3, number was interpreted as URI (on your example). But when you dial, number has digits (and  +,*) only: then it should be interpreted as number not as URI. Then you should be going down on the diagram (instead of right). Also, phone will add CUCM IP address as domain, then no change there.

 

In other words, what i think is missing here the ILS routing box when  LHS is number only.

 

What do you think?

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

Hey Alex, long time...

If you are referring to example 2 of case study 2, then the reason the number is interpreted as URI is due to the dial string implementation policy. This was set to treat all dial strings as URI. SO even if you dial a numeric pattern it will be treated as URI

aalejo
Level 5
Level 5
Hey Ayodeji
 
Really, I am not referring to any specific case, only that diagram does not have the ILS search box when LHS is interpreted as number. It does have the ILS box search if LHS is interpreted as Alpha...
 
Thanks!
Alex
 
Ayodeji Okanlawon
VIP Alumni
VIP Alumni

Hey Alex now I understand you. I guess the reason is that when LHS is numeric ,CUCM will use the already established number routing logic which is well documented and there is no point in adding it to the diagram. 

ryandowdy
Level 4
Level 4

This is one of my most often referred to posts in all of the Collaboration spaces. Thank you for taking the time to create this content. 

 

One question: From which Cisco Live presentation did you find the PPT screenshot with the call logic flowchart?

 

Thanks again

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: