911 calls from our CUBES are failing

[gp1200x]

Over the weekend something happened and all our 911 calls to Verizon are failing. We have two CUBES (back each other up with our network sites split between them) and 911 calls out both primary CUBES fail along with the backup call that gets retried on the secondary CUBE.

Verizon says they see 911 and not the number in their trace.  Except from part of their responses.

We reviewed SIP records corresponding to the provided call example. There were several attempts to reach 911 from your equipment at 152.187.182.42, but we were unable to authenticate these calls because the From field contained "911" rather than a valid TN associated with the SIP gateway at 152.187.182.42. Please check your equipment configuration and/or work with your equipment vendor to resolve this issue.

No known changes were made on the CUBES and they were not rebooted over the weekend. We have a Cisco CER and no one made changes that we know of. Where is the 911 coming from instead of the actual ELIN numbers for the sites when they call 911?  I have asked to have the CER rebooted. All other outbound and inbound calls through the CUBES are working correctly.


 

[Ayodeji Okanlawon]

We had a problem with CER to Verizon sip trunk a while back. The CLI on 911 calls were wrong. It turned out to be something with the diversion header on the cube sent by CER..

Can you send us a sample log from your cube

debug ccsip messages (include the calling number)

[gp1200x]

The calling number 8454862465 does not show up in the trace...I think it would possibly be masked by the elin numbers?? 

But in this case the calls to 911 show up as calling from 911

I think the first 911 call starts around 8:54:07.961    using dial peer 502

some failure around  8:54:27.161   dial peer 501

an another possible around  8:55:01.265   unless they are all retries by the CM

[Chris Deren]

It looks like the INVITE is going with calling number as 911:

INVITE sip:911@172.22.209.2:5060 SIP/2.0
Via: SIP/2.0/TCP 172.22.196.3:5060;branch=z9hG4bK8e46355a62e35b
From: <sip:911@172.22.196.3>;tag=9770296~6faf4609-af95-42b9-a971-0e80e755aec8-46242792

which is not what Verizon would expect, Verizon does ANI screening and would require 10 digit DID.

Here is the cancel request:

213444: Jan 21 08:55:05.429: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received: 
CANCEL sip:911@172.22.209.2:5060 SIP/2.0
Via: SIP/2.0/TCP 172.22.196.3:5060;branch=z9hG4bK8e46355a62e35b
From: <sip:911@172.22.196.3>;tag=9770296~6faf4609-af95-42b9-a971-0e80e755aec8-46242792
To: <sip:911@172.22.209.2>
Date: Wed, 21 Jan 2015 13:54:10 GMT
Call-ID: f8273280-4bf1af82-d3776-3c416ac@172.22.196.3
CSeq: 101 CANCEL
Max-Forwards: 70
Content-Length: 0

[gp1200x]

Problem resolved with Annese and Cisco help.

Apparently a tech made a change on the CM over the weekend or Friday night.

Change backed off by Cisco.

Issue resolution as follows:

Resolution: Set Calling Party Select field in CUBE to Originator.

IN CUCM:

• Select Device

  • Trunk (or CUBE)

    • Router

      • Outbound Calls

        • Calling Party Select

          • Originator

Operation:

User dials 911:

1. CUCM routes call to CER

2. CER:

   1. Matches switch port to assigned ERL/ELIN

   2. Instructs CUCM to Release (drop) the original call from the user

   3. Sends a 911 call to CUCM with ELIN as CID

   4. CUCM processes CER call out to SIP Trunk

   5. CER call hits CUBE (Router) with ELIN CID, which is registered on the SIP provider trunk, as the originator CID.

[Chris Deren]

Exactly, this is what happens when someone changes things :-)

Let us know if you need further assistance, if not you can mark the thread as answered.

[Ayodeji Okanlawon]

Chris is correct (+5), something is not right with the calling number. It shouldn't be showing 911. It should show a valid DDI registered with your ITSP so as to clearly identify who the 911 call is for