Solved: 1 way communication for one specific DN

Xenophanes00 · ‎03-29-2012

I'm operating a CallManager 6.1 system with about 200 phones. Recently, one particular DN has been unable to receive calls, although they can still be placed. I've placed that line on two phones to make sure that it wasn't just a hardware issue with the phone. Incoming q931 debug reveals this:

Mar 29 11:07:06: ISDN Se0/0/1:23 Q931: RX <- SETUP pd = 8 callref = 0x006A

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98389

Exclusive, Channel 9

Facility i = 0x9F8B0100A10F02010106072A8648CE1500040A0100

Protocol Profile = Networking Extensions

0xA10F02010106072A8648CE1500040A0100

Component = Invoke component

Invoke Id = 1

Operation = InformationFollowing (calling_name)

Name information in subsequent FACILITY message

Progress Ind i = 0x8283 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '212-------'

Plan:ISDN, Type:National

Called Party Number i = 0x80, '01819'

Plan:Unknown, Type:Unknown

Mar 29 11:07:06: ISDN Se0/0/1:23 Q931: TX -> SETUP_ACK pd = 8 callref = 0x806A

Channel ID i = 0xA98389

Exclusive, Channel 9

Mar 29 11:07:06: ISDN Se0/0/1:23 Q931: RX <- STATUS pd = 8 callref = 0x006A

Cause i = 0x82E1 - Message type not implemented

Call State i = 0x06

I checked the hex error code descriptions, but they don't give me much insight into what might be happening. The most curious thing to me is that it's only effecting this particular DN, and for the few weeks since it went into service, this line had been behaving normally. I'd like to change it, but the extension has been publicized for use.

Other symptoms are that when a call attempts to connect, the phones which carry that line will very briefly flash as if they were about to ring, and then the screen will display that a call was missed (with the correct incoming line's information). From the outside perspective, the call simply gets disconnected after a few moments of silence.

Any suggestions on where I might look for clues next?

Thanks!

abarkalg · ‎03-31-2012

Hi Shane,

Try setting the service parameter "Overlap receiving flag for PRI" to false . I am suspecting that the pattern overlaps with something else that has more digits, so we send setup ack instead of call proceeding as we can accept more digits due to the existence of a potential match.

Regards,

Abdul

Please rate helpful posts!!!!

View solution in original post

ronpatel · ‎03-29-2012

Hi,

What about internal phone to cluster. Are they able to call the DN.

Regards

Ronak Patel

Regards Ronak Patel Rate all helpful post by clicking stars below the answer.

Xenophanes00 · ‎03-30-2012

Yes, other phones internal to the cluster can call that line without any problem.

It's only when the PRI attempts to set up an incoming call from the PSTN that the problem appears.

paolo bevilacqua · ‎03-30-2012

Can you take another debug for a working case and post here?

The status message from CO is very, very strange.

Also please specify if MGCP or H.323.

Xenophanes00 · ‎03-30-2012

This is a working call to an operating DN on the same equipment - MGCP

Voice3825A#

Mar 30 20:01:45: ISDN Se0/0/1:23 Q931: RX <- SETUP pd = 8 callref = 0x0173

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Facility i = 0x9F8B0100A10F02010106072A8648CE1500040A0100

Protocol Profile = Networking Extensions

0xA10F02010106072A8648CE1500040A0100

Component = Invoke component

Invoke Id = 1

Operation = InformationFollowing (calling_name)

Name information in subsequent FACILITY message

Progress Ind i = 0x8283 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '212-------'

Plan:ISDN, Type:National

Called Party Number i = 0x80, '07071'

Plan:Unknown, Type:Unknown

Mar 30 20:01:45: ISDN Se0/0/1:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x8173

Channel ID i = 0xA98381

Exclusive, Channel 1

Mar 30 20:01:45: ISDN Se0/0/1:23 Q931: TX -> ALERTING pd = 8 callref = 0x8173

Progress Ind i = 0x8088 - In-band info or appropriate now available

Mar 30 20:01:46: ISDN Se0/0/1:23 Q931: RX <- FACILITY pd = 8 callref = 0x0173

Facility i = 0x9F8B0100A117020101020100800F574952454C4553532043414C4C4552

Protocol Profile = Networking Extensions

0xA117020101020100800F574952454C4553532043414C4C4552

Component = Invoke component

Invoke Id = 1

Operation = CallingName

Name Presentation Allowed Extended

Name = WIRELESS CALLER

Mar 30 20:01:51: ISDN Se0/0/1:23 Q931: TX -> CONNECT pd = 8 callref = 0x8173

Mar 30 20:01:51: ISDN Se0/0/1:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0173

Mar 30 20:01:56: ISDN Se0/0/1:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x0173

Cause i = 0x8290 - Normal call clearing

Mar 30 20:01:56: ISDN Se0/0/1:23 Q931: TX -> RELEASE pd = 8 callref = 0x8173

Mar 30 20:01:56: ISDN Se0/0/1:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0173

Voice3825A#un all

paolo bevilacqua · ‎03-31-2012

Then there is a configuration difference between the two numbers, because in the working case, Cm sends CALL_PROCEEDING, instead of SETUP_ACK.

Anyway, the first trace is incomplete. Is not said that CO closes communication after sending STATUS:

TIm: in this case CM never sends calling name to CO, so that is not the cause of the problem.

abarkalg · ‎03-31-2012

Hi Shane,

Try setting the service parameter "Overlap receiving flag for PRI" to false . I am suspecting that the pattern overlaps with something else that has more digits, so we send setup ack instead of call proceeding as we can accept more digits due to the existence of a potential match.

Regards,

Abdul

Please rate helpful posts!!!!

Xenophanes00 · ‎03-31-2012

Abdul,

This has fixed the problem! But if this was the solution, then the *real* problem of an overlapping pattern still exists underneath this workaround. This is confusing for me because only one DN matches x1819, and more strangely - if I completely delete the DN and Unity VM associated with it - the error would still persist.

This line worked just fine for several weeks without this trouble so something must've changed to cause this problem. Only one thing to my knowledge was added: a series of Route Patterns to match outgoing area codes. I wouldn't think that this would matter though, since my understanding is that Route Patterns are not evaluated for incoming calls. Perhaps coincidentally, one of those route patterns *did* match ( 9.1819! - to catch calls bound for an Internationally billable area code within NANP ). I deleted that matching route pattern suspecting it might be the problem, since I'd run out of other ideas, but even afterwards, the problem still persisted.

If there *is* still a matching pattern within my callmanager - how will I find it?! I've checked all the DNs, and CTIs for similar numbers, but came up empty so far. Is there a good way for me to methodically root it out?

Thanks again for the fix, but I'll feel better when I can reset that service back to its default after having found the true culprit!

-shane

abarkalg · ‎03-31-2012

Hi Shane,

The CSS for the gateway port probably has access to a route pattern that could send the call back out the PSTN. If you make sure the CSS on the gateway only has access to only 7-digit long dial strings that start with 9, it should work.

Hope this helps.

Regards,

Abdul

Please rate helpful posts !!!!

t.s.davis · ‎03-30-2012

Do you have 'isdn supp-service name calling' on your PRI serial interface? If so, try removing it. I have seen that 'Message type not implemented' error when calling name is configured but the carrier doesn't have it enabled on the circuit.

abarkalg · ‎03-31-2012

Hi Shane,

Try setting the service parameter "Overlap receiving flag for PRI" to false . I am suspecting that the pattern overlaps with something else that has more digits, so we send setup ack instead of call proceeding as we can accept more digits due to the existence of a potential match.

Regards,

Abdul

Please rate helpful posts!!!!