cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
995
Views
3
Helpful
6
Replies

AS5300 PSTN to SIP troubles

oeuftete_
Level 1
Level 1

I'm having problems getting an AS5300 to do a basic PSTN-to-SIP call. It looks like it should be easy... I'm more or less set up like the various sample configs out there. But it's never getting to the point of sending anything SIP. Can anyone help?

Here's what's going on, using "debug voip ccapi error":

May 3 15:08:21.230 UTC: //47/05A4378180C2/SSAPP:1:-1/ssaSetupPeer: setup failed rc(-5)

May 3 15:08:21.230 UTC: //47/05A4378180C2/CCAPI/ccGetCallActiveByCallID: cc_spi_call_get() returned -7. (setup_time=0x1FE71A5, index=0x1)

May 3 15:08:21.230 UTC: //47/05A4378180C2/CCAPI/cc_api_call_disconnect_done: cause=44,retry=0,vcCauseCode=0

A little more info with more debugging (calling number edited):

May 3 17:54:23.945 UTC: //48/37E015AC80C6/SSAPP:1:-1/ssaSetupPeer: dialpeer tags in rotary= 2

May 3 17:54:23.945 UTC: //48/37E015AC80C6/SSAPP:1:-1/ssaSetupPeer: cid(48), destPat(4746932), matched(7), prefix(), peer(62BE6C9C), peer->encapType (2)

May 3 17:54:23.945 UTC: //48/37E015AC80C6/CCAPI/ccCallProceeding: (callID=0x30, prog_ind=0x0)

May 3 17:54:23.945 UTC: //48/37E015AC80C6/CCAPI/ccCallProceeding:

May 3 17:54:23.945 UTC: //-1/xxxxxxxxxxxx/CCAPI/ccDupRawMsgInfo:

May 3 17:54:23.945 UTC: ccDupRawMsgInfo

May 3 17:54:23.945 UTC: //-1/xxxxxxxxxxxx/CCAPI/ccAllocRawMsgInfo: VoIP Raw Msg Alloc from 10, Length 200 Body 0

May 3 17:54:23.949 UTC: //-1/xxxxxxxxxxxx/CCAPI/ccAllocRawMsgInfo: Raw Message ALLOCATED: ptr is 629A1B70, owner is 10, length is 200, msg is 62D37844, type is 0, protocol id is 0

May 3 17:54:23.949 UTC: //48/37E015AC80C6/SSAPP:1:-1/ssaSaveRawMsg:

May 3 17:54:23.949 UTC: ssaSaveRawMsg: Dup-saved rawmsgpp 629A1B70 len 200

May 3 17:54:23.949 UTC: IAM,

PRN,isdn*,,NT100,

USI,rate,c,s,c,1

USI,lay1,ulaw

TMR,00

CPN,02,,1,4746932

CGN,04,,1,y,4,5555552693

CPC,09

FCI,,,,,,,y,

May 3 17:54:23.949 UTC: //48/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest:

May 3 17:54:23.949 UTC: Raw Message MaMa is TSP owner is SSAPP, length is 200, ptr is 629A1B70, type is 0, protocol id is 4

May 3 17:54:23.949 UTC: //48/37E015AC80C6/CCAPI/ccCallSetupRequest: (Inbound call = 0x30, outbound peer =2, dest=,

params=0x629B2058 mode=0, *callID=0x629B2628, prog_ind = 0callingIE_present 1)

May 3 17:54:23.949 UTC: //48/37E015AC80C6/CCAPI/ccCallSetupRequest:

May 3 17:54:23.949 UTC: ccCallSetupRequest numbering_type 0xC1

May 3 17:54:23.949 UTC: //48/37E015AC80C6/CCAPI/ccCallSetupRequest:

May 3 17:54:23.949 UTC: ccCallSetupRequest: decremented counter 0

May 3 17:54:23.949 UTC: //48/37E015AC80C6/SSAPP:1:-1/ssaSetupPeer: try next peer cid(48), rc(-5)

Anyone know what the "rc(-5)" corresponds to?

Finally, a little bit of relevant config.

dial-peer voice 1 pots

incoming called-number 4746932

direct-inward-dial

port 0:D

!

dial-peer voice 2 voip

destination-pattern 4746932

session protocol sipv2

session target sip-server

codec g711ulaw

!

sip-ua

sip-server ipv4:10.142.0.69

Finally, version:

Cisco Internetwork Operating System Software

IOS (tm) 5300 Software (C5300-IS-M), Version 12.3(13), RELEASE SOFTWARE (fc2)

6 Replies 6

Hello.

Do you have SIP leg debug ?

If yes , attach it.

> Do you have SIP leg debug ?

> If yes , attach it.

The SIP leg does not get started, so there are no debug messages, unfortunately.

Well.

send me kfedor@inbox.ru

following debugs

debug isdn q931

debug voice ccapi inout

I have sent the requested info. Thanks for looking into this.

oeuftete_
Level 1
Level 1

More information.

I also have the same problem in reverse, i.e. on SIP-to-PSTN calls. The dial peers are matched correctly and it looks like the PSTN leg is going to be attempted, but then the call is mysteriously disconnected without ever having started the PSTN leg. That is to say, I see no Q.931 messages being sent. This is much like the PSTN-to-SIP case above, where no SIP messages are being sent.

I have attached a debug log (q931, ccsip, dialpeer, ccapi inout) in case anyone would like to lend a set of eyes.

The problem is solved. There was a technology mismatch between the VCWare and the DSPs. This only became apparent to me on a reload.