unable to dial using softphone

[rrb555]

Hi,

Vicibox v4.0.0 RC2
VERSION: 2.6-375a
BUILD: 120831-1523

I want to share something about what I am experiencing now. we are dialing with no issue when agents login to agent interface. But when a manager wants to dial out using a softphone only he is unable to make outgoing calls "not a valid extension" where he did is just dial 91XXXXXXXXXX. where manager supposedly correct in using dial prefix 9 then 1 for country code followed by a US 10 digit.

So i checked cli output and here's what I've found
[Oct 9 16:58:56] -- Executing [20987654391XXXXXXXXXX@defaultlog:1] AGI("SIP/phone99999-00004966", "agi-NVA_recording.agi|BOTH------Y---Y---Y") in new stack
[Oct 9 16:58:56] -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-NVA_recording.agi
[Oct 9 16:58:56] -- AGI Script Executing Application: (Monitor) Options: (wav|/var/spool/asterisk/monitor/MIX/20121009165856_phone99999_20987654391XXXXXXXXXX)
[Oct 9 16:58:56] -- AGI Script agi-NVA_recording.agi completed, returning 0
[Oct 9 16:58:56] -- Executing [20987654391XXXXXXXXXX@defaultlog:2] Goto("SIP/phone99999-00004966", "default|20987654391XXXXXXXXXX|1") in new stack
[Oct 9 16:58:56] -- Goto (default,20987654391XXXXXXXXXX,1)
[Oct 9 16:58:56] -- Sent into invalid extension '20987654391XXXXXXXXXX' in context 'default' on SIP/phone99999-00004966
[Oct 9 16:58:56] -- Executing [i@default:1] Playback("SIP/phone99999-00004966", "invalid") in new stack
[Oct 9 16:58:56] -- <SIP/phone99999-00004966> Playing 'invalid' (language 'en')

not really sure how did 209876543 added in as I didn't input this anywhere in the dial plan of all the carriers i've created. What i am really sure that it is working fine when we are using dial prefix 9 in a campaign.

[williamconley]

Seems to me like you have either edited your .conf files (bad idea) or have custom dialplan entries that are interfering with your regular dialplan.

Show a successful dialer call with the same 91XXXXXXXXXX so we can see the difference. I bet it becomes obvious ...

Alternately, look at the context the manager is in to be sure it's default and not something else (just because the call ended up in default does NOT mean it started there!)