Caller ID Translation Issue

Answered Question
Sep 8th, 2010
User Badges:

Hi, I am having a problem with caller id. I am receiving something like 55E6E6D in the caller id. Is there any translation rule I can use to strip all the letters or replace them with digits? I am  using Cisco AS5400. Thanks.

Correct Answer by Steven Holl about 6 years 8 months ago

Oh it is coming in SIP with that.  Okay, well technically that should be valid since the from field can be a username instead of an e164 number.


I haven't tried applying this to see how it works, but it at least lets me create a voice translation rule with E's.


2821-Pod3(config)#voice translation-rule 1 
2821-Pod3(cfg-translation-rule)#rule 1 /^55E6B6E$/ /5551234567/


I was hoping you would collect the CCAPI output so that I could see what the ani in the call control stack is populated with.  Try applying that rule to a profile on the calling number on your inbound peer match.  If it doesn't work, get:


debug voip ccapi inout

debug ccsip all

debug voice translation

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Steven Holl Thu, 09/09/2010 - 10:47
User Badges:
  • Cisco Employee,

You are talking about the calling party number, and not the ISDN call ID (or call reference), right?  Are you sure that 'debug voip ccapi inout' shows the cisco-ani field as '55E6E6D?'  Can you paste the q931 and CCAPI debug output for a call?  The calling party number can be represented in hex, but I'd expect it to show as 0x55E6E6D instead of just 55E6E6D.


E is not a valid DTMF digit for a calling party number.  Hence, a translation isn't going to work.


Also, verify that your switch type confiugration matches the ISDN protocol which the provider has your cirucit provisioned for.

gengcisco Thu, 09/09/2010 - 21:04
User Badges:

Thank you so much for helping me. Yes, it is calling party number. The call comes in from the voip leg. Here is the output from the ccsip debug output. I only removed the IP address information. The calling number is 55E6B6E.


Sep  8 11:55:35 x.x.x.x 310976: Sep  8 11:55:35.393 PST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sep  8 11:55:35 x.x.x.x 310977: Received:
Sep  8 11:55:35 x.x.x.x 310978: INVITE sip:[email protected]:5060;user=phone;transport=udp SIP/2.0^M
Sep  8 11:55:35 x.x.x.x 310979: Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK+446def525b6404ca5149421b8b7d74361+x.x.x.x5060+1^M
Sep  8 11:55:35 x.x.x.x 310980: From: ;tag=x.x.x.x5060+1+350f0002+159091b4^M
Sep  8 11:55:35 x.x.x.x 310981: To: ^M
Sep  8 11:55:35 x.x.x.x 310982: CSeq: 539693533 INVITE^M
Sep  8 11:55:35 x.x.x.x 310983: Expires: 180^M
Sep  8 11:55:35 x.x.x.x 310984: Supported: replaces^M
Sep  8 11:55:35 x.x.x.x 310985: Request-Disposition: fork, sequential^M
Sep  8 11:55:35 x.x.x.x 310986: Allow: INVITE, BYE, REGISTER, ACK, OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, P
Sep  8 11:55:35 x.x.x.x 310987: RACK, INFO, REFER, UPDATE^M
Sep  8 11:55:35 x.x.x.x 310988: Call-ID: [email protected]^M
Sep  8 11:55:35 x.x.x.x 310989: Max-Forwards: 67^M
Sep  8 11:55:35 x.x.x.x 310990: Contact:  ^M
Sep  8 11:55:35 x.x.x.x 310991: Content-Type: application/sdp^M
Sep  8 11:55:35 x.x.x.x 310992: Content-Length: 267^M
Sep  8 11:55:35 x.x.x.x 310993: ^M
Sep  8 11:55:35 x.x.x.x 310994: v=0^M
Sep  8 11:55:35 x.x.x.x 310995: o=nt02-1w-lax 284636161 1283970704 IN IP4 x.x.x.x^M
Sep  8 11:55:35 x.x.x.x 310996: s=sip call^M
Sep  8 11:55:35 x.x.x.x 310997: c=IN IP4 x.x.x.x^M
Sep  8 11:55:35 x.x.x.x 310998: t=0 0^M
Sep  8 11:55:35 x.x.x.x 310999: m=audio 37516 RTP/AVP 18 0 101^M
Sep  8 11:55:35 x.x.x.x 311000: a=ptime:20^M
Sep  8 11:55:35 x.x.x.x 311001: a=fmtp:101 0-15^M
Sep  8 11:55:35 x.x.x.x 311002: a=rtpmap:101 telephone-event/8000^M
Sep  8 11:55:35 x.x.x.x 311003: a=rtpmap:0 PCMU/8000^M
Sep  8 11:55:35 x.x.x.x 311004: a=fmtp:18 annexb=no^M
Sep  8 11:55:35 x.x.x.x 311005: a=rtpmap:18 G729/8000^M
Sep  8 11:55:35 x.x.x.x 311006:
Sep  8 11:55:35 x.x.x.x 311007: Sep  8 11:55:35.393


Sep  8 11:55:49 x.x.x.x 311218: Sep  8 11:55:48.601 PST: //362422/7F68722F8879/SIP/Call/sipSPICallInfo:
Sep  8 11:55:49 x.x.x.x 311219: The Call Setup Information is:
Sep  8 11:55:49 x.x.x.x 311220: Call Control Block (CCB) : 0x69BAEA34
Sep  8 11:55:49 x.x.x.x 311221: State of The Call        : STATE_DEAD
Sep  8 11:55:49 x.x.x.x 311222: TCP Sockets Used         : NO
Sep  8 11:55:49 x.x.x.x 311223: Calling Number           : 55E6B6E
Sep  8 11:55:49 x.x.x.x 311224: Called Number            : 1051512142330030
Sep  8 11:55:49 x.x.x.x 311225: Source IP Address (Sig  ): x.x.x.x

Correct Answer
Steven Holl Fri, 09/10/2010 - 06:55
User Badges:
  • Cisco Employee,

Oh it is coming in SIP with that.  Okay, well technically that should be valid since the from field can be a username instead of an e164 number.


I haven't tried applying this to see how it works, but it at least lets me create a voice translation rule with E's.


2821-Pod3(config)#voice translation-rule 1 
2821-Pod3(cfg-translation-rule)#rule 1 /^55E6B6E$/ /5551234567/


I was hoping you would collect the CCAPI output so that I could see what the ani in the call control stack is populated with.  Try applying that rule to a profile on the calling number on your inbound peer match.  If it doesn't work, get:


debug voip ccapi inout

debug ccsip all

debug voice translation

gengcisco Fri, 09/10/2010 - 20:45
User Badges:

The translation rule worked. Thank you very much your help. I am wondering if it is possible to get a more general rule to get rid of the letters in the calling number in case something similar comes in.

Actions

This Discussion