CER for multisite variable length on-net dialplan customer

[Andy Backus]

Hello -

I am working to deploy CER for a large customer.  They have a CCM cluster supporting, as expmple, 10 sites with the following characteristics:

1. each site has 4 digit DNs

2. each site has it's own phone partition

3. sites have overlapping DNs

4. calling from one site to another requites "8" +"3 digit site code"

5. CCM 7.x;

6. CER 8.0

CER is populated with switches from multiple sites so therefore will have CER database entry for DN=4000 in site1, site2, and site 7.

Question are:

1. If site2, DN 4000 phone calls 911, how does CER associate this caller with ERL2?

    - I am not sure what parameters are passed in the JTAPI messaging to the 911 CER Route Point to make this association?

    - assume the basics are signalled like calling/called numbers, but is additional info like mac address passed allowing CER to map ERL accurately

2. PSAP Callback

   -assuming ERL is mapped correctly on the outbound 911 call, if PSAP calls  back and ELIN is routed back to CER properly ...

   - CER would perform callback using ELIN<=>Phone cached mapping

                  o hence CER would send JTAPI call request to CCM for x4000

                  o x4000 exists in 3 partitions

   - if I have the CER911 CTI Route Point CSS populated with each sites phone partition, it would seem that CCM would incorrectly ring the first partition listed that contained x4000

SRND for variable length onnet design has section on CER but nothing of value (at least that I could find).   Same with the CER docs.

Any guidance here would really be appreciated.

Thanks

Andy

[Chris Deren]

Andy,

1. you assign a particular switchport or VLAN to ERL, so if you have phoneA with DN 4000 in site1 and phoneB with DN 4000 in site2 they are obviously connected to different switches hence assigned to different ERLs using different ELINs

2. This one I am unsure of as JTAPI is not partition aware, however I am not sure what relationship is kept between CUCM and CER for the callback, if it is DN then it will not work properly, if it is something else i.e. device name then it should be no problem.

The question here is why are you doing partitioned dial plan, is there a requirement to restrict one site from calling another site? Normally you would use flat addressing with variable length dial plan and not worry about these issues. In fact I personally re-designed several similar environments where intially customer deployed exactly what you have and realized they would run into multiple issues as JTAPI was never partition aware and applications such as UCCX, CUEAC, CER, etc will not play nicely here. Even Voicemail integration will present issues.

HTH,

Chris

[Andy Backus]

Hello Chris, thanks for the reply.

So, while the switchport is pecified and used to populate the CER db, that is all done before any call is made.  At that point, CER has DN, MAC, IP,...

Phone makes 911 call, and at this point, CER has to tie this "inbound call" to a phone in the database.  That association has to use information from the JTAPI messaging which I assume to be standard compliant.  I could be way off here because we just did a test where a phone, defined in CER using switch port, was matched up properly even though I totally changed the callerid on 911 call (i.e. phone dn=4613, phone translation for 911 prefixed changed to 1111 so CER sees calling num=1111).  This callerID was not stored anywhere in CER database but it did match up the correct zone.  I have no idea how.  JTAPI must pass in mac/IP which CER uses.

As for the partitioning, we came in after the fact and it could not easily be changed.

Andy

[Chris Deren · Accepted solution]

So, while the switchport is pecified and used to populate the CER db, that is all done before any call is made.  At that point, CER has DN, MAC, IP,...

Correct, you build CER configuration to your design

 Phone makes 911 call, and at this point, CER has to tie this "inbound call" to a phone in the database.  That association has to use information from the JTAPI messaging which I assume to be standard compliant.  I could be way off here because we just did a test where a phone, defined in CER using switch port, was matched up properly even though I totally changed the callerid on 911 call (i.e. phone dn=4613, phone translation for 911 prefixed changed to 1111 so CER sees calling num=1111).  This callerID was not stored anywhere in CER database but it did match up the correct zone.  I have no idea how.  JTAPI must pass in mac/IP which CER uses.

For outbound call, when phone dials 911 and the call is routed to CER via CTI RP, CER maps this call to a phone that dialed 911 through discovered DN from the Switch via SNMP/CDP, it then identifies which port the phone is connected to, looks at what ERL is assigned to the port and uses next available ELIN on that ERL to mask ANI to it and route it to CUCM. CUCM routes the call via Route Pattern to CUCM with the modified Caller ID.

When the call drops and 911 agent needs to call back, they dial the ELIN DID, call is routed to CUCM, matches translation pattern that routes the call to CER via another CTI RP (usually 913XXXXXXXXXX), CER sees the call coming in with ELIN and checks internal db for who last called out using this ELIN, and extends the call to that phone DN, it keeps that relationship for up to 3 hours after the call was made.

HTH, please rate all useful posts!

Chris

[Andy Backus]

Thanks Chris -

It turns out that more information is used for mapping the outbound call to the correct phone in the CER db.  I changed the user 911 translation pattren so that the calling number was no where in the CER db, and it still mapped it correctly. Therefore, I assume that the JTAPI signalling includes the mac address as one of the paramters.  

With that, we were able to design around any limitations.

Thanks for the info.

Andy

[will.alvord]

Are you talking about the pstn callback flow?

[Andy Backus]

Hello Will -

Nope, talking about the original, outbound 911 call.  As a test, I used the user 911 translation pattern (which in turn refers to the 911 CTI RP) to set the calling number to a random number, say 1111111.  CER was still able to map this "DN" to the valid phone even though 1111111 had nothing to do with the actual phone DN.  Again, this is where I assumed that the JTAPI signalled paramters included more than basic call setup parameters such as calling/called number. 

You might ask why we were doing this ... well, I could not get an exact answer from Cisco on how this mapping was implemented.  This info was required because we had overlapping DNs (i.e. DN 4000 would exist in several sites/zones). We needed more information on the matching algorithm to insure that calls from phones that had DNs in multiple locations could be differentiated (when I say 'DNs in multiple locations' I do not mean shared lines).

Very interesting.

Andy

[will.alvord]

CER matches inbound calls in 3 ways:

• switch port
• subnet
• calling party number

The 1st 2 are probably self-explanatory based on how you configure CER.  The 3rd is probably the least used method and involves adding "manual phone" entries in CER.  So unless you added 'manual phones' in CER, CER will ignore the calling party number (directory number).  CER is most scalable if you're using subnet tracking, and less so by far if you're using switchport tracking and manual phone tracking.

If you have an overlapping dialplan #3 is probably out as an option unless you want to feel the pain of all of that digit manipulation.  You're left with either #1 or #2.  If your voice subnets don't have any overlap then that would be easier from an administrative perspective as well as provide for more scalability.  If they do overlap, then you're essentially left with #1 (which I believe you said you're doing anyways).

To satisfy your curiosity, define a manual phone entry (1111111 using your example) and assign whatever test ERL you want.  I believe that the order of precedence is switches, then subnets, and then manual phones.  So in order for this test to be successful make sure that your test phone is not tracked via any switches or subnets defined in CER.