SIP/ISDN disconnect problem

v_bashaev · ‎10-16-2009

Hello to all! We have a bit of a problem

Our customer has a geographically spread voip. Central site and spokes. Some spokes have local phone ports only and are connected via h.323 peers, some have local pbx connected via sip and gateways there only do number manipulation in sip-to-sip calls.

The lineup is like this: Panasonic TDA200 through E1 Pri (net5 type) to Cisco3825 to Cisco2811 through SIP to Panasonic PBX with SIP card. The problem is that when remote user on sip-emabled panasonic is busy, local user calling him on tda200 trough E1 to 3825 and then through vpn tunnel to 2811 waits for ~30 secs and then gets reorder instead of getting immediate busy tone. When the user is not busy the communication establishes but I have no info about delays.

I have enabled gateway accounting and debugged isdn q931. Dialing panasonic sends 3 digits enblock and then adds 1 in overlap, it cannot do otherwise. That's ok. What I cannot understand is that gw accounting reasonably shows that the call started and ended at the same time and code was user busy. But the gw sends to originating ISDN channel DISCONNECT message only some 30 secs later with normal call clearing code.

To our knowledge this only happens with sip-connected voip spokes, in h.323 there is no such thing.

What could cause that?

debug info:

****************************************

*Oct 16 10:03:50.779: ISDN Se0/3/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0022

Bearer Capability i = 0x9090A3

Standard = CCITT

Transfer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA1839E

Preferred, Channel 30

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

Calling Party Number i = 0x2180, '328'

Plan:ISDN, Type:National

Called Party Number i = 0x81, '600'

Plan:ISDN, Type:Unknown

*Oct 16 10:03:50.783: ISDN Se0/3/0:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0x8022

Channel ID i = 0xA9839E

Exclusive, Channel 30

*Oct 16 10:03:50.951: ISDN Se0/3/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0022

Called Party Number i = 0x81, '8'

Plan:ISDN, Type:Unknown

*Oct 16 10:03:50.959: ISDN Se0/3/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8022

Kievskaya#

*Oct 16 10:03:51.287: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 2, ConnectionId 9B275DCB97211DE95F20024C4168480, SetupTime *10:03:50.957 UTC Fri Oct 16 2009, PeerAddress 6008, PeerSubAddress , DisconnectCause 11 , DisconnectText user busy (17), ConnectTime *10:03:51.287 UTC Fri Oct 16 2009, DisconnectTime *10:03:51.287 UTC Fri Oct 16 2009, CallOrigin 1, ChargedUnits 0, InfoType 2, TransmitPackets 0, TransmitBytes 0, ReceivePackets 0, ReceiveBytes 0

*Oct 16 10:03:51.287: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:10/16/2009 10:03:50.955,cgn:328,cdn:6008,frs:0,fid:57757,fcid:9B275DCB97211DE95F20024C4168480,legID:E1B8,bguid:09B275DCB97211DE95F20024C4168480

Kievskaya#

*Oct 16 10:04:21.291: ISDN Se0/3/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x8022

Cause i = 0x8290 - Normal call clearing

*Oct 16 10:04:21.323: ISDN Se0/3/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x0022

*Oct 16 10:04:21.327: ISDN Se0/3/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x8022

peers configuration:

3825:

dial-peer voice 14 pots

destination-pattern [123]..

port 0/3/0:15

forward-digits all

dial-peer voice 117 voip

description outg to Kursk SIP

destination-pattern 60..

session protocol sipv2

session target ipv4:172.17.100.9

dtmf-relay h245-alphanumeric

codec g729br8

2811:

dial-peer voice 11 voip

description outgoing to local SIP PBX

translation-profile outgoing IP_to_Local

destination-pattern 60..

session protocol sipv2

session target ipv4:192.168.6.200

codec g729br8

dial-peer voice 20 voip

description incoming from IP to SIP PBX

session protocol sipv2

incoming called-number 60..

dtmf-relay h245-alphanumeric

codec g729br8

Thanks for tips in advance.

paolo bevilacqua · ‎10-16-2009

Can you take "debug isdn q931" and "debug ccsip message" ? Do not enable other debugs.

v_bashaev · ‎10-16-2009

I have finally brought my message to readable form. The isdn debug is in the message itself. Any ideas?

I will take sip debug and post it but I don't know how it will help as gw accounting probably takes info from sip messages, so they should show timing and codes to be expected but not ocurring..

paolo bevilacqua · ‎10-16-2009

debug ccsip message is needed to see what PBX is actually sending, it is not safe to infer things when troubleshooting.

Also metnion exact IOS version please.

v_bashaev · ‎10-16-2009

here is the consolidated debug. please see the attachment as it doesn't fit in 4000 letters.

notice weird thing: user 350 calls 6008.

panasonic dials 600 and adds 8 as info.

later there are two gw acc records:

the last one goes for 350 to 600 and correlates with isdn timing... (shows gap in time and states normal clearing)

what is it I wonder?

paolo bevilacqua · ‎10-16-2009

Which exact IOS is this ?

(as asked before).

v_bashaev · ‎10-16-2009

here are sw versions:

3825

Cisco IOS Software, 3800 Software (C3825-ADVIPSERVICESK9-M), Version 12.4(15)T9,

RELEASE SOFTWARE (fc5)

Technical Support: http://www.cisco.com/techsupport

Compiled Tue 28-Apr-09 17:45 by prod_rel_team

ROM: System Bootstrap, Version 12.4(13r)T11, RELEASE SOFTWARE (fc1)

2801: (sorry, it is 2801, not 2811 as I stated before)

Cisco IOS Software, 2801 Software (C2801-ADVIPSERVICESK9-M), Version 12.4(15)T7,

RELEASE SOFTWARE (fc3)

Technical Support: http://www.cisco.com/techsupport

Compiled Wed 13-Aug-08 18:11 by prod_rel_team

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

paolo bevilacqua · ‎10-16-2009

Try upgrading for example, 12.4(22)YB4 and check again.

v_bashaev · ‎10-16-2009

that is not easily possible. one router is many miles away and have slow and jerky internet connectivity. and I don't see good reason for that: these images are quite good and stable. do you still think that it is not a configuration issue but a software bug?

paolo bevilacqua · ‎10-16-2009

Yes. Check "show sip-ua map sip-to-pstn" and you will see the mapping is correct, but does not happen.

Please remember to rate useful posts with the scrollbox below.

v_bashaev · ‎10-16-2009

I've issued that command.

Here's the result:

Kievskaya#sh sip-ua map sip-pstn

The SIP Status code to PSTN Cause mapping table:-

SIP-Status Configured Default

PSTN-Cause PSTN-Cause

400 127 127

401 57 57

402 21 21

403 57 57

404 1 1

405 127 127

406 127 127

407 21 21

408 102 102

409 41 41

410 1 1

413 127 127

414 127 127

415 79 79

416 127 127

417 63 63

420 127 127

422 127 127

480 18 18

481 127 127

482 127 127

483 127 127

484 28 28

485 1 1

486 17 17

487 16 16

488 127 127

500 41 41

501 79 79

502 38 38

503 63 63

504 102 102

505 127 127

580 49 49

600 17 17

603 21 21

604 1 1

606 58 58

Don't know what you mean.

Anyway, no sip-ua is used. We use sip dial-peers without sip-server. Just peers. On sip-enabled panasonic in remote location with some help from the manufacturer the need to register on server was removed and so it also works in peer-to-peer configuration.

paolo bevilacqua · ‎10-16-2009

As the header says, means SIP cause 486 maps to ISDN cause 17. But in your cause that does not happen.

Even if you don't configure it, sip-ua is enabled anyway in the router. It-s just part of the whole SIP process.

v_bashaev · ‎10-16-2009

I got it and I see SIP 486 busy in debug

but I don't get the point - in the very first post I've already said that gw acc shows good code so sip should do the same..

I'm worried about the "extra" gw accounting syslog message with false destination number in the last line. What can it relate too?

We can upgrade software in the hub node.. but it means getting bugs. Actually we had nat-related bugs in newer releases so this one was chosen for stable operation.

It could well be that solving this problem via sw upgrade will cause some more severe complications.

paolo bevilacqua · ‎10-16-2009

As you noted, IOS has many bugs, one can be the number is syslog, I did not paid attention to that.

You can only hope that at one point you find an image where everything works, or if you have a support contract, complain to the TAC.

Please remember to rate useful posts with the scrollbox below.

paolo bevilacqua · ‎10-16-2009

I searched and found a severity 2 bug. Ignore the fact is about H.323 and a different IOS, it may very well apply to you.

CSCtb99736

H323 disconnect cause is not fowarded to application

Symptom: ISDN Cause codes are not being forwarded transparently to the PBX.

Conditions: Issue was found with 7206VXR running 12.4(22)T1

Workaround: none