Cannot dial out. X added to extension number

SIP phone can receive but when trying to dial to another internal extension for example 512, the call fails and shows that it is trying to reach 512x (note the “x” at the end).

This is Asterisk 1.4.24, FreePBX 2.5.1.0 running on CentOS.

The test setup is only for 3 internal extensions: 511, 512 and 513.
510: X-Lite 3.0
511: D-Link DPH-540
512: D-Link DPH-540

Extensions 510 and 512 behave correctly and can call/receive to/from other extensions. Extension 511 can only receive but cannot call out.

Both D-Link phones are known to work as they were re-configured from a previous Asterisk setup. They are supposedly similarly configured (I compared the Web admin screens line by line). They are correctly registered with Asterisk and their output from “show sip peer” are also very similar (see listing for 511 below).

The debug log shows that somehow when 511 is dialing out to any other extension, an “x” gets added to the end of the receiving extension hence making the number invalid. This doesn’t occur when calling from the other extensions.

I have spent several hours trying to sort out this problem and I am running out of ideas. Any suggestion on where to look will be very much appreciated!

SIP SHOW PEER 511:

  • Name : 511
    Secret :
    MD5Secret :
    Context : from-internal
    Subscr.Cont. :
    Language :
    AMA flags : Unknown
    Transfer mode: open
    CallingPres : Presentation Allowed, Not Screened
    Callgroup :
    Pickupgroup :
    Mailbox : 511@device
    VM Extension : *97
    LastMsgsSent : 0/0
    Call limit : 50
    Dynamic : Yes
    Callerid : “device” <511>
    MaxCallBR : 384 kbps
    Expire : 1788
    Insecure : no
    Nat : RFC3581
    ACL : Yes
    T38 pt UDPTL : No
    CanReinvite : No
    PromiscRedir : No
    User=Phone : No
    Video Support: Yes
    Trust RPID : No
    Send RPID : No
    Subscriptions: Yes
    Overlap dial : Yes
    DTMFmode : rfc2833
    LastMsg : 0
    ToHost :
    Addr->IP : 192.168.1.11 Port 5060
    Defaddr->IP : 0.0.0.0 Port 5060
    Def. Username: 511
    SIP Options : (none)
    Codecs : 0x1c000c (ulaw|alaw|h261|h263|h263p)
    Codec Order : (ulaw:20,alaw:20)
    Auto-Framing: No
    Status : OK (125 ms)
    Useragent : Callctrl/1.6.0.0 MxSF/v3.5.3.4
    Reg. Contact : sip:511@192.168.1.11:5060

DEBUG LOG:

[Apr 7 14:48:28] VERBOSE[10159] logger.c: – Executing [512x@from-internal:1] ResetCDR(“SIP/511-b7700468”, “”) in new stack
[Apr 7 14:48:28] VERBOSE[10159] logger.c: – Executing [512x@from-internal:2] NoCDR(“SIP/511-b7700468”, “”) in new stack
[Apr 7 14:48:28] VERBOSE[10159] logger.c: – Executing [512x@from-internal:3] Wait(“SIP/511-b7700468”, “1”) in new stack
[Apr 7 14:48:29] VERBOSE[10159] logger.c: – Executing [512x@from-internal:4] Playback(“SIP/511-b7700468”, “silence/1&cannot-complete-as-dialed&check-number-dial-again|noanswer”) in new stack
[Apr 7 14:48:29] VERBOSE[10159] logger.c: – <SIP/511-b7700468> Playing ‘silence/1’ (language ‘en’)
[Apr 7 14:48:30] VERBOSE[10159] logger.c: – <SIP/511-b7700468> Playing ‘cannot-complete-as-dialed’ (language ‘en’)
[Apr 7 14:48:33] VERBOSE[10159] logger.c: – <SIP/511-b7700468> Playing ‘check-number-dial-again’ (language ‘en’)
[Apr 7 14:48:35] VERBOSE[10159] logger.c: – Executing [512x@from-internal:5] Wait(“SIP/511-b7700468”, “1”) in new stack
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Executing [512x@from-internal:6] Congestion(“SIP/511-b7700468”, “20”) in new stack
[Apr 7 14:48:36] VERBOSE[10159] logger.c: == Spawn extension (from-internal, 512x, 6) exited non-zero on ‘SIP/511-b7700468’
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Executing [h@from-internal:1] Macro(“SIP/511-b7700468”, “hangupcall”) in new stack
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Executing [s@macro-hangupcall:1] ResetCDR(“SIP/511-b7700468”, “vw”) in new stack
[Apr 7 14:48:36] DEBUG[10159] app_macro.c: Executed application: ResetCDR
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Executing [s@macro-hangupcall:2] NoCDR(“SIP/511-b7700468”, “”) in new stack
[Apr 7 14:48:36] DEBUG[10159] app_macro.c: Executed application: NoCDR
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Executing [s@macro-hangupcall:3] GotoIf(“SIP/511-b7700468”, “1?skiprg”) in new stack
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Goto (macro-hangupcall,s,6)
[Apr 7 14:48:36] DEBUG[10159] app_macro.c: Executed application: GotoIf
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Executing [s@macro-hangupcall:6] GotoIf(“SIP/511-b7700468”, “1?skipblkvm”) in new stack
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Goto (macro-hangupcall,s,9)
[Apr 7 14:48:36] DEBUG[10159] app_macro.c: Executed application: GotoIf
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Executing [s@macro-hangupcall:9] GotoIf(“SIP/511-b7700468”, “1?theend”) in new stack
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Goto (macro-hangupcall,s,11)
[Apr 7 14:48:36] DEBUG[10159] app_macro.c: Executed application: GotoIf
[Apr 7 14:48:36] VERBOSE[10159] logger.c: – Executing [s@macro-hangupcall:11] Hangup(“SIP/511-b7700468”, “”) in new stack
[Apr 7 14:48:36] VERBOSE[10159] logger.c: == Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘SIP/511-b7700468’ in macro ‘hangupcall’
[Apr 7 14:48:36] VERBOSE[10159] logger.c: == Spawn extension (from-internal, h, 1) exited non-zero on ‘SIP/511-b7700468’

ADDITIONAL DATA:

Another extension # 5820 was added and the 511 extension could dial out to it! It still could not dial to either the #510 or #512.

I wonder if #511 is a reserved extension in Asterisk? Although so far I have not found any document specifying such allocation for 511.

To me seems the problem is in the phone, not in Asterisk, so check the phone’s digits map (or phone’s dial plan) of the 511 phone, I think there is an extra “x” at the end of the string that determines the acceptable digits,.

Cheers.

Marco Bruni
www.marcobruni.net

Dear Marco,

Thank you for your reply.

Nothing could be found in the phone which defined the dial plan. So the 511 extension in Asterisk was deleted and recreated anew. No change. The phone extension in both the phone and Asterisk were changed from 511 to 4405, still no improvement.

The DPH-540 was then reset to factory default and re-configured anew with 511. This resolved the problem and the phone behaved correctly from that point on!

So you were right, the problem was in the phone.