0

Test environment consists of a CSipSimple client, Asterisk server and a router with NAT. Formerly the equipment used UDP port 5060 and everything was good. Then I changed port number to 15000 in Asterisk, in router's forwarding rule and in client app. Now, when accessing the net from outside, client can register, but when it calls some extension, Asterisk complains about inability to create DAHDI channel. When client is in the LAN, calls are working.

What went wrong? I changed only control port number.

Update

At first place I need to mention that Asterisk always complains about inability to create DAHDI channel when I am calling extension number 100, no matter whether the voice works or not. So, this error message could be ignored.

Now, the differing tails of verbose call logs:

Mobile client registered over 3G, no sound (call, pickup, timeout):

-- SIP/103-00000001 answered SIP/101-00000000
   > 0x7fda800295a0 -- Probation passed - setting RTP source address to 192.168.1.100:5062

That's all. No further messages.

Mobile client registered over WiFi, sound works (call, pickup, conversation, hangup):

  -- SIP/103-00000003 answered SIP/101-00000002
     > 0x7fda88026620 -- Probation passed - setting RTP source address to 192.168.1.100:5062
     > 0x7fda78013fb0 -- Probation passed - setting RTP source address to 192.168.1.112:4000
     > 0x7fda78013fb0 -- Probation passed - setting RTP source address to 192.168.1.112:4000
  -- Executing [h@macro-dial-one:1] Macro("SIP/101-00000002", "hangupcall,") in new stack
  -- Executing [s@macro-hangupcall:1] GotoIf("SIP/101-00000002", "1?theend") in new stack
  -- Goto (macro-hangupcall,s,3)
  -- Executing [s@macro-hangupcall:3] ExecIf("SIP/101-00000002", "0?Set(CDR(recordingfile)=)") in new stack
  -- Executing [s@macro-hangupcall:4] Hangup("SIP/101-00000002", "") in new stack
== Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/101-00000002' in macro 'hangupcall'
== Spawn extension (macro-dial-one, h, 1) exited non-zero on 'SIP/101-00000002'
== Spawn extension (macro-dial-one, s, 43) exited non-zero on 'SIP/101-00000002' in macro 'dial-one'
== Spawn extension (macro-exten-vm, s, 9) exited non-zero on 'SIP/101-00000002' in macro 'exten-vm'
== Spawn extension (from-internal, 103, 2) exited non-zero on 'SIP/101-00000002'
  • Just to be clear - you changed the SIP port number on your client and Asterisk and router? But left RTP ports unchanged? – TSG Jul 4 '15 at 14:52
  • @Telium: Yes, I changed control port number everywhere, but left RTP port unchanged. Actually I believe that RTP ports are chosen randomly in some range of values and can't be changed. Correct me if I'm wrong. Additionally I can say that I had no dstnat rules for RTP ports and it worked. – Paul Jul 4 '15 at 15:40
2

I suspect your SIP port is now in the RTP range, so Asterisk doesn't realize this is a SIP connection. Either move the SIP port or move the RTP port range so they don't overlap.

Please capture the CLI output of a failed call (off LAN) and a succesfull call (on LAN) and post the results here.


To capture the CLI output, from the bash prompt:

asterisk -r
core set verbose 10

Then make a call from your LAN which works, Then make a call from outside your LAN which fails Post the full output of the above (I assume you have a simple dialplan). I you are using a canned PBX like Elastix or FreePBX the output may be too long to post here...

| improve this answer | |
  • I'm having trouble imaging why internal (LAN client) calls will bridge but external (off-LAN client) calls won't. I think you are not sharing something important. Please post Asterisk CLI output with verbose set to 10 showing a successfull call and a failed call. – TSG Jul 5 '15 at 12:22
  • 1
    Instructs added above – TSG Jul 7 '15 at 13:29
  • The output above doesn't make sense - are you sure you set verbose to 10? If you did, it suggests a dialplan problem and that 3G calls must be coming in a different trunk....still doesn't make sense. You need to post more output – TSG Jul 7 '15 at 21:52
  • Setting SIP control port to 5162 helped. The inability to get voice was when port had been set to 5540 although RTP range was set to 10100-10120. And yeah, to configure settings through FreePBX an appropriate module should be installed. – Paul Jul 8 '15 at 0:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.