Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

1 way communication for one specific DN

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!

1 ACCEPTED SOLUTION

Accepted Solutions
New Member

1 way communication for one specific DN

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!!!!

10 REPLIES
Blue

1 way communication for one specific DN

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.
New Member

1 way communication for one specific DN

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.

Hall of Fame Super Gold

Re: 1 way communication for one specific DN

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.

New Member

Re: 1 way communication for one specific DN

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

Hall of Fame Super Gold

Re: 1 way communication for one specific DN

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.

New Member

1 way communication for one specific DN

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!!!!

New Member

1 way communication for one specific DN

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

New Member

1 way communication for one specific DN

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 !!!!

New Member

Re: 1 way communication for one specific DN

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.

New Member

1 way communication for one specific DN

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!!!!

456
Views
0
Helpful
10
Replies