Cisco 2811 <--> Asterisk not able to answer calls

General Help
1

Hi,

Having problems with a Cisco 2800 series router configured as a CUBE to terminate all of our voice circuits before going over to Asterisk.

Call flows all look good. I have an external DID set to ring directly on an extension. When I dial the external number on my cell phone, I get through to the extension and it starts ringing. When I pickup nothing happens.

Watching packets on the Asterisk server, I can see this (172.22.4.12 CUBE, 172.22.4.8 Asterisk);

U 172.22.4.12:59803 -> 172.22.4.8:5061
INVITE sip:[email protected]:5061 SIP/2.0.

U 172.22.4.8:5061 -> 172.22.4.12:5060
SIP/2.0 100 Trying.

U 172.22.4.8:5061 -> 172.22.4.12:5060
SIP/2.0 180 Ringing.

U 172.22.4.8:5061 -> 172.22.4.12:5060
SIP/2.0 180 Ringing.

### Pick up handset to answer

U 172.22.4.8:5061 -> 172.22.4.12:5060
SIP/2.0 200 OK.

U 172.22.4.12:59803 -> 172.22.4.8:5061
ACK sip:[email protected]:5061 SIP/2.0.

U 172.22.4.12:59803 -> 172.22.4.8:5061
BYE sip:[email protected]:5061 SIP/2.0.

U 172.22.4.8:5061 -> 172.22.4.12:5060
SIP/2.0 200 OK.

U 172.22.4.12:59803 -> 172.22.4.8:5061
INVITE sip:[email protected]:5061 SIP/2.0.

U 172.22.4.8:5061 -> 172.22.4.12:5060
SIP/2.0 100 Trying.

### Process repeats from here, until I hang up on my cell.

The config of my trunk on Asterisk is;

PEER
host=172.22.4.12
type=friend
context=from-trunk
insecure=invite,port
trustrpid=yes
sendrpid=yes
directmedia=no
qualify=yes
keepalive=45
nat=no
dtmfmode=rfc2833
disallow=all
allow=ulaw,alaw
canreinvite=no

I’m not as familiar with debug logs on the Cisco, but nothing obvious really jumped out at me as being a problem…

2

Note that the Cisco device is hanging up the call. You’ll need to figure out why it’s hanging up. As it’s accepting it and then hanging up, it’ll be something with the error checking - possibly no route, or some codec misconfiguration.

I’d get the person who configured it up to crank up the debug and do some googling.

Edit: Gold Coast? Hi from Gladstone :sunglasses:

3

Hello up there on the Central Coast, yes Gold Coast here. I spent a week camping in Tannum Sands a few years ago, nice place and friendly people…

The problem - I configured the Cisco (considering I’m CCNA Voice, it’s frustrating). The debugs are big, and there are many of them to enable etc.

I’m going to try a few things in the config - separate the dial peer (so, currently it matches the same dial-peer for incoming and outgoing). Also, the dial-peer that has the upstream SIP server in it is using a DNS SRV record, perhaps that’s not properly supported in IOS12.4…

In my defence, CCNA Voice isn’t that great, it really only covers off CUCM GUI administration and not really any CME CLI stuff…

edit: I don’t think the dial-peer with the upstream SIP server as the target makes any bearing to this, it shouldn’t be using that for the incoming leg of the call, and should be just using the source IP to reply on. Just that, I randomly see some different IP’s in some debug output - this router also has some dial-peer to get inbound calling into an old Asterisk server still …

4

My dial-peer configuration, in case there are some Cisco experts lurking here;

dial-peer voice 20 pots
 incoming called-number .
 direct-inward-dial
 port 0/1/0:15
 forward-digits all
dial-peer voice 300 voip
 destination-pattern 61756363540
 voice-class codec 1
 session protocol sipv2
 session target ipv4:172.22.4.6:5060
 session transport udp
 incoming called-number .
 dtmf-relay rtp-nte
dial-peer voice 400 voip
 translation-profile outgoing OUTGOING
 destination-pattern 9.T
 voice-class codec 1
 session protocol sipv2
 session target dns:sipb.onthenet.com.au
 session transport udp
 dtmf-relay rtp-nte
 no vad
dial-peer voice 501 voip
 destination-pattern 617567.....
 voice-class codec 1
 session protocol sipv2
 session target ipv4:172.22.4.8:5061
 session transport udp
 incoming called-number 617567.....
 dtmf-relay rtp-nte
 no vad

I wrote dial-peer 501, the others were put in there by another engineer. So, incoming called-number is matching for incoming dial-peer and then destination-pattern is matched for outgoing dial-peer.

5

Tannum’s nice, yeah. The kids love going there for a swim :sunglasses: We actually have a small property at Rosedale (on the way to Bundy) that we go camping and motorbiking on, too!

I went down the CCIE Security track, and that was a long time ago (I’ve been expired for more than 10 years now) in which I only barely touched on VoIP. I can’t offer you any help, unfortunately, either. Sorry :sunglasses:

–Rob

6

Hiya Rob,

Heard you on the FreePBX Live show the other day, nice to hear a local accent :slight_smile: and yes, also interesting in any training that you can bring to Australia. I got a little excited, because I thought if it ever happens chances are it might happen in Brissie first :smiley:

I’m still not having any luck with my issue. I get disconnect cause=127 from the Cisco debugs which afaik means nothing. I’ve attached a debug (nope, can’t attach txt files try this instead http://pastebin.com/tBSA76aB), I know you’re not exposed to this much anymore but I’m reaching out anywhere I can.

I also wonder (due to experiences with PJSIP and Cisco 79xx’s) that maybe it doesn’t like chan_sip on port 5061. Is it possible to setup an unauthenticated PJSIP trunk?

Anyway, I’m drawing blanks - there mustn’t be a lot of difference between chan_sip on Asterisk 11 versus Asterisk 13…

7
Received: CANCEL sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 121.50.206.27;rport;branch=z9hG4bK34pZUvrtKgcHa Max-Forwards: 66 From: "61429920437" ;tag=Z41t7Z0rUK9aQ To: Call-ID: f2b898e2-ca1d-1233-f08a-4ae403f50289 CSeq: 80155230 CANCEL Reason: SIP;cause=487;text="ORIGINATOR_CANCEL" Content-Length: 0
8

Hi Rob,

Thanks for looking at it for me. The packet you quoted above is when i hang up my mobile phone to disconnect the call.

The part that seems to have the error, or rather, where the CUBE sends a BYE to my PBX - this happens when I try to answer the ringing call.

So it goes…

Aug 31 10:56:19: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 172.22.4.12:5060;branch=z9hG4bK9EC23AC;received=172.22.4.12

Aug 31 10:56:26: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.22.4.12:5060;branch=z9hG4bK9EC23AC;received=172.22.4.12

Aug 31 10:56:26: cc_api_get_xcode_stream : 4181
Aug 31 10:56:26: //2101/EC91C7E3805D/CCAPI/ccCallDisconnect:
   Cause Value=127, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Aug 31 10:56:26: //2101/EC91C7E3805D/CCAPI/ccCallDisconnect:
   Cause Value=127, Call Entry(Responsed=TRUE, Cause Value=127)
Aug 31 10:56:26: //2100/EC91C7E3805D/CCAPI/ccCallDisconnect:
   Cause Value=127, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Aug 31 10:56:26: //2100/EC91C7E3805D/CCAPI/ccCallDisconnect:
   Cause Value=127, Call Entry(Responsed=TRUE, Cause Value=127)

Aug 31 10:56:26: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent: 
ACK sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/UDP  172.22.4.12:5060;branch=z9hG4bK9ED111E

Aug 31 10:56:26: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent: 
BYE sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/UDP  172.22.4.12:5060;branch=z9hG4bK9EE8A3

It’s that Cause Value=127 that has me confused. This is the hangup cause generated by the Cisco router when I try to answer the call, the CUBE disconnects and immediately sends another INVITE.

Cisco says that this means;

Indicates that there has been interworking with a network that does not provide causes for actions it takes. Precise cause cannot be ascertained.

Also maps it to SIP cause code 500 - Internal Server Error, and in fact we see the Cisco send this to the ITSP;

Aug 31 10:56:26: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent: 
SIP/2.0 500 Internal Server Error
Via: SIP/2.0/UDP 120.29.4.75;rport;branch=z9hG4bKp5X4S7cSrpF2e
From: "61429920437" <sip:[email protected]>;tag=UF5B97U141jHp
To: <sip:[email protected]>;tag=102881A4-F18
Date: Mon, 31 Aug 2015 00:56:18 GMT
Call-ID: ee58fdc6-ca1d-1233-d6a2-4ae403f50289
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 80155225 INVITE
Allow-Events: telephone-event
Reason: Q.850;cause=127
Content-Length: 0

Seeing as though we are the ITSP as well, I might do a packet capture from those servers and check logs there. Maybe that will give more indication. These just seem like a very generic cause code. I also did a debug and watched a successful call through this device into an Asterisk 11 server and there wasn’t much difference between the two (although, I didn’t pick up a call, an IVR did pick it up).

9

I keep thinking it’s a codec issue somewhere. Can you make sure you haven’t tried to block all codecs (disallow=all) anywhere?

10

HI Rob,

I did have a disallow=all in my trunk configuration, so I took this out and tried again but got the same error.

Here is my trunk config, I only have this in PEER settings - this is because it’s set to type=friend which I read means that the trunk will use the same settings in PEER as USER. Is that right?

host=172.22.4.12
type=friend
context=from-trunk
insecure=invite,port
trustrpid=yes
sendrpid=yes
directmedia=no
qualify=yes
keepalive=45
nat=no
dtmfmode=rfc2833
disallow=all (removed this line)
allow=ulaw,alaw
canreinvite=no
force_rport=no

Might be worth the mention - but I can successfully dial out via this trunk with no problems.

11

I duplicated the working trunk config in Asterisk 11 over to the 13 server as per;

PEER
type=friend
qualify=yes
nat=no
insecure=very
host=172.22.4.12
dtmfmode=rfc2833
context=from-trunk
allow=ulaw

User Context: from-trunk

USER
type=friend
qualify=yes
nat=no
host=172.22.4.12
dtmfmode=rfc2833
context=from-trunk
canreinvite=no
allow=ulaw

Same problem exists with this config as well…

12

The logs on our upstream servers doesn’t give much more help either, which I didn’t think they would as it’s the Cisco that’s disconnecting the call… but;

2015-09-02 09:48:08.246838 [DEBUG] sofia.c:5811 Channel sofia/internal-private/[email protected] entering state [proceeding][180]
2015-09-02 09:48:08.246838 [NOTICE] sofia.c:5906 Ring-Ready sofia/internal-private/[email protected]!
2015-09-02 09:48:08.246838 [DEBUG] switch_channel.c:3239 (sofia/internal-private/[email protected]) Callstate Change DOWN -> RINGING
2015-09-02 09:48:10.416836 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal-private/[email protected] [BREAK]
2015-09-02 09:48:10.416836 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal-private/[email protected] [BREAK]
2015-09-02 09:48:10.416836 [DEBUG] switch_core_session.c:1016 Send signal sofia/internal-private/[email protected] [BREAK]
2015-09-02 09:48:10.416836 [DEBUG] sofia.c:5811 Channel sofia/internal-private/[email protected] entering state [terminated][500]
2015-09-02 09:48:10.416836 [NOTICE] sofia.c:6655 Hangup sofia/internal-private/[email protected] [CS_CONSUME_MEDIA] [INTERWORKING]
13

That’s the only thing that jumps out at me on the cisco as being different. And the ‘no vad’ line, but I dont’ know why that would cause an issue.

14

Those lines shouldn’t cause an issue but I turned on VAD, and removed the extra dial-peer I had created as the incoming peer which had the incoming called-number matching. Now incoming called-number matches against a wildcard, and destination-pattern is used for matching as per;

dial-peer voice 501 voip
 destination-pattern 617567.....
 voice-class codec 1
 session protocol sipv2
 session target ipv4:172.22.4.8:5061
 session transport udp
 incoming called-number .
 dtmf-relay rtp-nte

I am going to try set this trunk up as PJSIP… I learnt from the 79xx’s handsets that Cisco can be picky with what SIP stack you’re using and which ports it receives on. I tried this originally, and couldn’t get a PJSIP trunk to come up with some user/pass auth details…

15

So your upstream server is FreeSwitch? If so I would stick with SIP for now . . .

16

@dicko This is correct.

Stick with chan_sip?

17

IWFM, not so much pjsip yet. . . .

18

My concern was that the Cisco device doesn’t like port 5061 in there. Although - outbound is working so surely that must count for something.

What is it that works for you, dicko? You mean SIP from FS to Asterisk? That’s been working fine for me… Or, are you talking about a similar setup to me with a Cisco 2811 as a border?

By the way, wanted to take a second to say thanks for the speedy help on this forum. I’ve also posted my problem to Cisco forums and asterisk-users mailing list without really any replies. Considering this would be regarded off-topic for here, I’m appreciative that you guys are trying to help out.

19

It would depend on what is on 5061 (5060 and 5061 both expose you to the knuckledraggers out there, but that is a different story :wink: ) it is either way a non-sequitur, chan_sip (asterisk) and sofia (freeswitch) are both a lot more mature than pjsip and both support UDP/TCP, I would go with a protocol that is tried and interworking on both ends.

20

Solid advice … Well, I had luck with PJSIP this time but the same problem still exists.

Handset rings, Asterisk sends 200 OK to Cisco when I pick up and Cisco immediately sends back BYE to Asterisk and 500 Internal Server Error to upstream FS servers. The error cause Cisco gives is 127 - the Q.850 equivalent of a SIP 500.