Re: PRI ANI

s.backus · ‎03-15-2022

I have a Cisco 3945 with a ISDN PRI connected to a T1 card.

Is there a command that will allow me to view the calling ANI and DN for a call that's already in progress? I don't want to leave debugs running as this creates other issues, so I need the ability to identify calling info without the debug on.

b.winter · ‎03-15-2022

Hi,

"show call active voice brief" or "show call active voice compact" will show you all active call legs.

s.backus · ‎03-15-2022

Thanks for the reply.

show call active voice brief provides lots of detail regarding the call legs including the IP of the Cisco (internal) station, but doesn't identify the ANI or TN of the calling or receiving party. The IP is useful as long as the internal station isn't an analog port.

show call active voice compact again provides the IP of the Cisco station, but still doesn't identify the ANI or TN of the parties.

For both commands, ANI for the external party is not provided and only a station/port IP is provided for the internal caller.

I'm looking to identify the ANI and TN for the calling/receiving parties for a call that's already in progress when debugs are not running.

b.winter · ‎03-15-2022

What you mean, the ANI is not provided?

The output for show call active voice compact looks like this:

 <callID>  A/O FAX T<sec> Codec       type        Peer Address       IP R<ip>:<udp>        VRF
Total call-legs: 2
    205993 ANS     T2     g711alaw    VOIP        P+49xxxxxxx      10.x.x.x:30846                   NA
    205994 ORG     T2     g711alaw    VOIP        P+39yyyyyyy    81.y.y.y:27896                    NA

Where the red is the calling number (ANI) and blue is the called number (DNIS).

The same numbers are seen when using show call active voice brief:

<ID>: <CallID> <start>ms.<index> (<start>) +<connect> pid:<peer_id> <dir> <addr> <state>
  dur hh:mm:ss tx:<packets>/<bytes> rx:<packets>/<bytes> dscp:<packets violation> media:<packets violation> audio tos:<audio tos value> video tos:<video tos value>
 IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late>
  delay:<last>/<min>/<max>ms <codec> <textrelay> <transcoded

 media inactive detected:<y/n> media cntrl rcvd:<y/n> timestamp:<time>

 long duration call detected:<y/n> long duration call duration :<sec> timestamp:<time>
 LostPacketRate:<%> OutOfOrderRate:<%>
 LocalUUID:<%> RemoteUUID:<%>
 VRF:<%>
  MODEMPASS <method> buf:<fills>/<drains> loss <overall%> <multipkt>/<corrected>
   last <buf event time>s dur:<Min>/<Max>s
 FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n>
  <codec> (payload size)
 ATM <protocol> [int vpi/vci cid] vad:<y/n> dtmf:<y/n> seq:<y/n>
  <codec> (payload size)
 Tele <int> (callID) [channel_id] tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
  MODEMRELAY info:<rcvd>/<sent>/<resent> xid:<rcvd>/<sent> total:<rcvd>/<sent>/<drops>
         speeds(bps): local <rx>/<tx> remote <rx>/<tx>
 Proxy <ip>:<audio udp>,<video udp>,<tcp0>,<tcp1>,<tcp2>,<tcp3> endpt: <type>/<manf>
 bw: <req>/<act> codec: <audio>/<video>
  tx: <audio pkts>/<audio bytes>,<video pkts>/<video bytes>,<t120 pkts>/<t120 bytes>
 rx: <audio pkts>/<audio bytes>,<video pkts>/<video bytes>,<t120 pkts>/<t120 bytes>



Telephony call-legs: 0
SIP call-legs: 2
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
STCAPP call-legs: 0
Multicast call-legs: 0
Total call-legs: 2
2    : 206004 539504470ms.1 (16:17:20.734 CET Tue Mar 15 2022) +60 pid:1000 Answer +49xxxxxxx connected
 dur 00:00:05 tx:280/56000 rx:283/56600 dscp:0 media:0 audio tos:0xB8 video tos:0x0
 IP 10.x.x.x:30854 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711alaw TextRelay: off Transcoded: No ICE: Off
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a
 LostPacketRate:0.00 OutOfOrderRate:0.00
 LocalUUID:74bbb218d860bf2df9cb56cab8905261
 RemoteUUID:79818d3dd3f456728eb4227d5f89b7e6
 VRF: NA
2    : 206005 539504470ms.2 (16:17:20.734 CET Tue Mar 15 2022) +60 pid:2000 Originate +39yyyyyyy connected
 dur 00:00:05 tx:283/56600 rx:280/56000 dscp:0 media:0 audio tos:0xB8 video tos:0x0
 IP 81.y.y.y:18252 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711alaw TextRelay: off Transcoded: No ICE: Off
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a
 LostPacketRate:0.00 OutOfOrderRate:0.00
 LocalUUID:79818d3dd3f456728eb4227d5f89b7e6
 RemoteUUID:74bbb218d860bf2df9cb56cab8905261
 VRF: NA

And again, you will see 2 entries for 1 call => 1 call always has 2 call legs.

s.backus · ‎03-15-2022

Interesting that you're seeing ANI. This is what I see for show call active voice compact:

<callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp> VRF
Total call-legs: 2
423 ORG T168 g729r8 VOIP P 147.xxx.xxx.xxx:20596
422 ORG T168 g729r8 TELE P

For show call active voice brief:

Total call-legs: 2
12C0 : 423 1099204060ms.1 (14:51:54.687 UTC Tue Mar 15 2022) +0 pid:0 Originate connecting
dur 00:02:13 tx:6651/133020 rx:6643/132860 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 147.xxx.xxx.xxx:20596 SRTP: off rtt:0ms pl:130870/20ms lost:1/0/0 delay:0/60/70ms g729r8 TextRelay: off Transcoded:

Any suggestions for what needs to be added to my config to get that information to populate?

b.winter · ‎03-15-2022

Maybe the calling party isn't sending any number at all.

What should also be fixed is, that at least one of the call legs is using dial-peer 0, which should be avoided in every case!

12C0 : 423 1099204060ms.1 (14:51:54.687 UTC Tue Mar 15 2022) +0 pid:0 Originate connecting

Which protocoll are you using on the voip side? H.323 or SIP?

Could you post the output of the debugs:

debug isdn q931

debug voice ccapi ind 1

debug voice ccapi ind 2

debug voice ccapi ind 74

Roger Kallberg · ‎03-15-2022

By the look the OP is likely using MGCP. You don't get the same output then.

@s.backus Do your self a favor and move to this century by moving to SIP as the protocol for the integration to/from CM.

s.backus · ‎03-15-2022

Most of my trunking is SIP, but MGCP does have a certain niche arena that makes it a necessity for certain applications

Roger Kallberg · ‎03-15-2022

If possible would you please give example of the use case(s) for using MGCP. It was many years ago since we moved off using MGCP, so I have a gap in this area.

s.backus · ‎03-15-2022

I know calling party is sending ANI as it appears on receiving phone display. Also, ANI doesn't display on outbound calls.

This is configured as MGCP

Unfortunately, I can't post the debugs due to security.

b.winter · ‎03-15-2022

Then, I would follow @Roger Kallberg's advice and change to GW connection to SIP.

Probably it's like Roger said, that you don't see it, because of the MGCP integration, but I can't verify this on my own, because I don't have access to a MGCP GW.

Is it possible to send the config, without any sensitive lines like user/pwd, IP's, ...?

Nithin Eluvathingal · ‎03-15-2022

Thats a normal behavior when using MGCP, as @Roger Kallberg suggested move to SIP as H323 will be deprecated soon.