Solved: Caller ID Translation Issue

gengcisco · ‎09-08-2010

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.

Steven Holl · ‎09-10-2010

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

View solution in original post

Steven Holl · ‎09-09-2010

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 · ‎09-09-2010

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:1051512142330030@x.x.x.x: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: <55E6B6E>;tag=x.x.x.x5060+1+350f0002+159091b4^M
Sep 8 11:55:35 x.x.x.x 310981: To: <1051512142330030>^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: 7B11890-325AA7@x.x.x.x^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: <55E6B6E>^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

Steven Holl · ‎09-10-2010

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 · ‎09-10-2010

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.

Steven Holl · ‎09-11-2010

It's just a regular expression, so you can be more generic with the match, sure.

Look at the following document for specific examples. If you want to overwrite everything, just use /^.*/ as the mach string.

http://www.cisco.com/en/US/partner/tech/tk652/tk90/technologies_configuration_example09186a00803f818a.shtml