first call thru sipxecs to openacd, first issue so far
Douglas Hubler
with sipxecs pick up the call!
I ran into one problem directing the call to the agent, freeswitch was
attempting to dial an invalid number
S E T U P
===========
Agent Login
User ID: 201
Password: 1234
VoIP Endpoint: SIP URI
VoIP Endpint Data: 2...@freebird.hubler.us
Use outband ring: Checked
Administration Setup/Media Types/freeswitch_media_manager
Dial String: {ignore_early_media=true}sofia/freebird.hubler.us/$1
P R O B L E M
==============
When call was put in queue and agent became available, freeswitch
could not reach the agent.
FreeSWITCH console gave this output trying to call agent 201
2010-06-16 10:34:43.683134 [DEBUG] mod_erlang_event.c:477 got data
<document type="freeswitch/xml">
<section name="directory">
<domain name="freebird.hubler.us">
<user id="201">
<params>
<param name="dial-string"
value="sofia/internal/sip:2...@freebird.hubler.us"/>
</params>
</user>
</domain>
</section>
</document> after 39 milliseconds from testme@freebird for
4df3e458-7954-11df-97a0-bf2c13f5473d!
2010-06-16 10:34:43.683134 [DEBUG] mod_erlang_event.c:484 XML parsed OK!
2010-06-16 10:34:43.683134 [ERR] mod_sofia.c:3286 Invalid Profile
2010-06-16 10:34:43.683134 [NOTICE] mod_sofia.c:3468 Close Channel N/A [CS_NEW]
2010-06-16 10:34:43.686044 [DEBUG] switch_core_state_machine.c:428 ()
Running State Change CS_DESTROY
2010-06-16 10:34:43.686044 [DEBUG] switch_core_state_machine.c:439
(N/A) State DESTROY
2010-06-16 10:34:43.686044 [DEBUG] mod_sofia.c:341 N/A SOFIA DESTROY
2010-06-16 10:34:43.686044 [DEBUG] switch_core_state_machine.c:439
(N/A) State DESTROY going to sleep
2010-06-16 10:34:43.686044 [ERR] switch_ivr_originate.c:2430 Cannot
create outgoing channel of type [sofia] cause:
[DESTINATION_OUT_OF_ORDER]
2010-06-16 10:34:43.686044 [DEBUG] switch_ivr_originate.c:3228
Originate Resulted in Error Cause: 27 [DESTINATION_OUT_OF_ORDER]
2010-06-16 10:34:43.686044 [ERR] switch_ivr_originate.c:2430 Cannot
create outgoing channel of type [user] cause:
[DESTINATION_OUT_OF_ORDER]
2010-06-16 10:34:43.686044 [DEBUG] switch_ivr_originate.c:3228
Originate Resulted in Error Cause: 27 [DESTINATION_OUT_OF_ORDER]
2010-06-16 10:34:43.686044 [DEBUG] handle_msg.c:98 Sending bgapi reply
to testme@freebird
T E M P H A C K
==================
From FreeSWITCH console I knew this dial string worked
> originate sofia/freebird.hubler.us/sip:2...@freebird.hubler.us 200
So I modified src/freeswitch_media_manager.erl around line 532 from
"sofia/internal/sip:"++Agent#agent.endpointdata;
to
"sofia/freebird.hubler.us/sip:"++Agent#agent.endpointdata;
and call went thru.
Q U E S T I O N
================
Did i configure my system wrong, or does OpenACD need a new VoIP
endpoint option for me to call external users?
Andrew Thompson
Yeah, I think this is mainly an oversight, or arguably an unanticipated
configuration.
To do this right, we'd need a setting for configuring how to call
arbitrary sip URIs, or something, in addition to the already existing
configuration option for how to make outbound calls to the PSTN.
You *could* also configure freebird.hubler.us as a gateway so you could
dial it like:
sofia/gateway/freebird/201
but that doesn't really help with the underlying issue, it just makes
the syntax a little cleaner.
I think the real solution is to have a dial string for *all* the
possible endpoints (SIP URI, h.323, IAX2, PSTN) (the PSTN one can
default to the dialstring for outbound calls, and the SIP one can
default to sofia/internal). If we use a dial string setting, we can even
do multiple sequential or serial dial strings (using the , and |
separators) - OpenACD already supports this.
Thoughts?
Andrew
Douglas Hubler
> possible endpoints (SIP URI, h.323, IAX2, PSTN) (the PSTN one can
> default to the dialstring for outbound calls, and the SIP one can
> default to sofia/internal). If we use a dial string setting, we can even
> do multiple sequential or serial dial strings (using the , and |
> separators) - OpenACD already supports this.
This dial string would be set in the agent login screen instead of
enumerating the different endpoints type?
So today it's like this
Username: _____
Password: _____
VoIP Endpoint: [SIP Registration | SIP URI | IAX2 URI | H323 URI |
PSTN NUMBER]
VoIP Endpoint Data: _____
Use outband ring: _
But you're suggesting something like this?
Username: _____
Password: _____
Dial String: _____
Use outband ring: _
Where dial string will be sent verbatim to FreeSWITCH?
Related Note
============
I just checked and I could have used the PSTN NUMBER option together
with my setting for
Administration UI on port 9999/Media Types/freeswitch_media_manager
Dial String = {ignore_early_media=true}sofia/freebird.hubler.us/$1
in combination with the agent endpoint data
sip:2...@freebird.hubler.us
to accomplish the call w/o having to hack the code.
Andrew Thompson
Actually, I was going to have them set alongside the other dial string
in the admin page.
Andrew
Andrew Thompson
> Actually, I was going to have them set alongside the other dial string
> in the admin page.
>
Looks like Micah did this this morning, you might want to give it a
look.
Andrew
Douglas Hubler
Adding the dial strings may have been clutch for my current situation.
GOAL
==========
I am now trying to login agents via Agent Dial Plan Listener (i.e. I
want my agents to log in and out via phone dialpad).
SETUP
========
If you recall my situation, FS does not hold my registrations, instead
I want FS/OpenACD to call a sip endpoint that is registered behind a
differnent SIP proxy (sipXecs). I was able to get this to work when
agents specify PSTN type endpoint in the web interface on port 5050,
but now i want to get this to work via dial_plan_listener.
PROBLEM
==========
I think the listener is only setup to handle the default sip_registration types:
agent_dialplan_listener.erl:81
...
case agent_dialplan_connection:start(Agent,
AgentAuth#agent_auth.securitylevel) of
{ok, Pid} ->
Endpoint = {sip_registriation, Username},
...
Here's my freeswitch dialplan and i can get the calls to hit this
extension no problem
<extension name="login">
<condition field="destination_number" expression="^login">
<action application="erlang_sendmsg"
data="agent_dialplan_listener testme@sipxecs agent_login
${sip_from_user}"/>
<action application="answer"/>
<action application="sleep" data="2000"/>
<action application="hangup" data="NORMAL_CLEARING"/>
</condition>
</extension>
QUESTION
===========
So I think I need to add login types to the Agent Dial Plan Listener,
only I'm not too clear on how the parameters pass from FS to OpenACD,
or if this is even the right approach.
Andrew Thompson
So the first problem is that sip_from_user isn't defined (or if its defined
its wrong). What does the dialplan on the sipX end look like that's
forwarding here? You'll probably need to pass the user ID after the
string 'login' and regex that out and pass it to the erlang call.
If you can make the call to an extension like login<username> you could
do something like this:
<condition field="destination_number" expression="^login(.+)$">
<action application="erlang_sendmsg" data="agent_dialplan_listener testme@sipxecs agent_login $1"/>$
...
</condition>
FYI, you probably don't need to answer or sleep, just hangup instantly.
And yes, I suspect we'll need to tell OpenACD how to reach that agent -
where are the agents you're trying to reach? We could probably pass
another parameter: 'type' which could be sip_registration, PSTN,
sip_URI, etc.
> QUESTION
> ===========
> So I think I need to add login types to the Agent Dial Plan Listener,
> only I'm not too clear on how the parameters pass from FS to OpenACD,
> or if this is even the right approach.
Andrew
Tony Graziano
Adding the dial strings may have been clutch for my current situation.On Thu, Jun 24, 2010 at 11:45 AM, Andrew Thompson <and...@hijacked.us> wrote:
> On Wed, Jun 16, 2010 at 12:18:36PM -0400, Andrew Thompson wrote:
>> Actually, I was going to have them set alongside the other dial string
>> in the admin page.
>>
>
> Looks like Micah did this this morning, you might want to give it a
> look.
GOAL
==========
I am now trying to login agents via Agent Dial Plan Listener (i.e. I
want my agents to log in and out via phone dialpad).
--
======================
Tony Graziano, Manager
Telephone: 434.984.8430
sip: tgra...@voice.myitdepartment.net
Fax: 434.984.8431
Email: tgra...@myitdepartment.net
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: help...@voice.myitdepartment.net
Fax: 434.984.8427
Helpdesk Contract Customers:
http://www.myitdepartment.net/gethelp/
Why do mathematicians always confuse Halloween and Christmas?
Because 31 Oct = 25 Dec.
Andrew Thompson
> via what kind of method? Would be nice to use the built-in method polycom
> has (softkeys).
I haven't set up softkeys on a polycom specifically, but if you can set
it just to dial an extension (like on a snom phone) then it'd be pretty
simple.
Andrew
Tony Graziano
Douglas Hubler
> So the first problem is that sip_from_user isn't defined (or if its defined
> its wrong). What does the dialplan on the sipX end look like that's
> forwarding here? You'll probably need to pass the user ID after the
> string 'login' and regex that out and pass it to the erlang call.
i see, i may not have included the full dialplan, but i'll look into
this i and understand your trick to get the user id
> FYI, you probably don't need to answer or sleep, just hangup instantly.
ok, good to know
> And yes, I suspect we'll need to tell OpenACD how to reach that agent -
> where are the agents you're trying to reach? We could probably pass
> another parameter: 'type' which could be sip_registration, PSTN,
> sip_URI, etc.
yes, this is the root of my question. I don't have a knack for erlang
yet to see how this goes. I see variables just magically appear out of
thin air in agent_dialplan_listener.erl and i cannot see how the
AgentAuth object is built from the parameters sent in the FS dialplan
connection string.
Andrew Thompson
AgentAuth is just the result of passing the username from the dialplan
to agent_auth:get_agent() which returns an authentication record
(defined in include/agent.erl as agent_auth). Because the agent's phone
endpoint isn't a property of their authentication (its per login).
So, the question is, how do we pass the endpoint type and the value
through to agent_dialplan_agent if they're not locally registered SIP
phones? Do we have some preconfigured endpoint they have, or do we pass
more arguments in the dialplan (if they're passed via the dialplan, how
does that data get to FreeSWITCH).
Any thoughts?
Andrew
Douglas Hubler
> So, the question is, how do we pass the endpoint type and the value
> through to agent_dialplan_agent if they're not locally registered SIP
> phones? Do we have some preconfigured endpoint they have, or do we pass
> more arguments in the dialplan (if they're passed via the dialplan, how
> does that data get to FreeSWITCH).
Having it passed in via the dialplan is definitely more flexible.
"I'm logging in, and here's how to reach me" I think it's natural.
If there is a preconfigured endpoint, I think it should be added only
as a convenience when someone wanted to reduce the configuration
steps. This is no different than the web login, i feel like the
agent_dialplan_listener was just missing that feature.
Andrew Thompson
The trick is, how do you get that data across via just a phone call? I
suppose you could hardcode the endpoint type and just substitute the
value, with the assumption that all your users were PSTN or whatever. If
you can make it work in your dialplan I can make it work on the backend.
Andrew
Douglas Hubler
> The trick is, how do you get that data across via just a phone call? I
> suppose you could hardcode the endpoint type and just substitute the
> value, with the assumption that all your users were PSTN or whatever. If
> you can make it work in your dialplan I can make it work on the backend.
What about this
<action application="set" data="type=pstn"/>
And then when it comes time to connect a fall, it could use the (new)
pstn dial string defined in the freeswitch_media_manager together with
the agent id to place the call.
So the case is more: "I'm logging in and use the PSTN dial string to
contact me" so there is some flexibility in the FS dial plans but not
enough to hang yourself.
All agents using that login number would be PSTN type, but that's
fine. Someone could setup a different login number if they wanted to
support multiple types.
BTW: Now that SIP endpoints have their own preconfigured dial string,
i think I should I be using sip instead of PSTN.
Andrew Thompson
> On Tue, Jul 6, 2010 at 7:50 PM, Andrew Thompson <and...@hijacked.us> wrote:
> > The trick is, how do you get that data across via just a phone call? I
> > suppose you could hardcode the endpoint type and just substitute the
> > value, with the assumption that all your users were PSTN or whatever. If
> > you can make it work in your dialplan I can make it work on the backend.
>
>
> What about this
>
> <action application="set" data="type=pstn"/>
>
> And then when it comes time to connect a fall, it could use the (new)
> pstn dial string defined in the freeswitch_media_manager together with
> the agent id to place the call.
This is a good idea, the only problem is we have one more missing bit of
information, the endpoint *data* (ie 5551234, which is seperate from the
agent's username). How do you want to pass that?
Douglas Hubler
> This is a good idea, the only problem is we have one more missing bit of
> information, the endpoint *data* (ie 5551234, which is seperate from the
> agent's username). How do you want to pass that?
i see, for me I assume the agent's user name _can_ be used to build
the agent endpoint contact string together with the dial string
configured in the freeswitch_media_manager. I require sip
registrations to match the user names in openacd. I can see how this
is not exactly generic.
There really is no real elegant way to pass along each agent's user
name in the FS dial plans. Also. agents managing their individual
PSTN/SIP/Other dial string would a mess to bulk edit and probably all
be the same.
This may be over engineering, but maybe it's the starting point of a
simpler design...
What if agents can optionally set just what their endpoint id would
be. So openacd agent with user name "joe" could configure his
endpoint id to "200". "200" would be passed by the FS dialplans and
looked up to match the OpenACD user name "joe". Then in the
freeswitch_media_manager, either variable could be used to build the
final dial string using the preconfigured system dial string.
j...@pbx.example.com or 2...@pbx.example.com
Only problem i see with this, is folks could have a separate endpoint
ids for each of the endpoint types. I feel like endpoint types
should be a boundless array I configure as an admin, i add a endpoint
type for each of the types of calls i'd like to support. Today,
knowing an agent can initiate a H323 call is probably a mistake and
i'd like it not available. With this boundless array, as an admin I
can name the items and build a select list on the login screen where
admins can specify more useful names like "internal extension" or
"home phone" and can not allow them to set any part of the dial string
other than the endpoint id and endpoint type.
here's the fancy part, the final dial string is determined when the
agent logs in not when the call is placed so if someone wanted to
build a crazy connector that builds a dial string based on more
flexible input, they still could.
Andrew Thompson
> On Tue, Jul 6, 2010 at 8:59 PM, Andrew Thompson <and...@hijacked.us> wrote:
> > This is a good idea, the only problem is we have one more missing bit of
> > information, the endpoint *data* (ie 5551234, which is seperate from the
> > agent's username). How do you want to pass that?
>
> i see, for me I assume the agent's user name _can_ be used to build
> the agent endpoint contact string together with the dial string
> configured in the freeswitch_media_manager. I require sip
> registrations to match the user names in openacd. I can see how this
> is not exactly generic.
>
No that's fine, lets do that. If someone needs to login via the PSTN we
can use their callerid or something in a custom dialplan. I don't really
see the need to overengineer this.
Andrew
Douglas Hubler
> No that's fine, lets do that. If someone needs to login via the PSTN we
> can use their callerid or something in a custom dialplan. I don't really
> see the need to overengineer this.
two things to implement this:
1.) get the endpoint type from FS sendmsg
2.) set the endpoint type in the registry
On topic #2, I tried hardcoding the endpoint type to pstn and to my
surprise, it still attempted looking for internal registrations
File:agent_dialplan_listener.erl:83
case agent_dialplan_connection:start(Agent,
AgentAuth#agent_auth.securitylevel) of
{ok, Pid} ->
Endpoint = {pstn, Username},
?WARNING("~s logged in with endpoint ~p", [Username, Endpoint]),
INCORRECT
=============
Trying to use agent_dialplan_listener (dialpad) to login, I then see
16:31:11 [NOTICE] <0.187.0>@gen_cdr_dumper:196 got update for agent_state
16:31:11 [WARNING] <0.176.0>@agent_dialplan_listener:84 201 logged
in with endpoint {pstn,"201"}
...
16:31:26 [NOTICE] <0.165.0>@freeswitch_media_manager:549 returning
${sofia_contact(2...@sipxecs.hubler.us)} for user directory entry 201
CORRECT
=============
Conversely when i use agent_web_listener(web ui:5050) to login, all works fine
16:39:42 [NOTICE] <0.187.0>@gen_cdr_dumper:196 got update for agent_state
16:39:42 [WARNING] <0.180.0>@agent_web_listener:409 201 logged in
with endpoint {pstn,"201"}
...
16:39:56 [NOTICE] <0.165.0>@freeswitch_media_manager:549 returning
{ignore_early_media=true}sofia/sipxecs.hubler.us/sip:2...@sipxecs.hubler.us
for user directory entry 201
Andrew Thompson
> On Wed, Jul 7, 2010 at 10:42 AM, Andrew Thompson <and...@hijacked.us> wrote:
> > No that's fine, lets do that. If someone needs to login via the PSTN we
> > can use their callerid or something in a custom dialplan. I don't really
> > see the need to overengineer this.
>
> two things to implement this:
> 1.) get the endpoint type from FS sendmsg
> 2.) set the endpoint type in the registry
>
> On topic #2, I tried hardcoding the endpoint type to pstn and to my
> surprise, it still attempted looking for internal registrations
>
Try it now.
Andrew
Douglas Hubler
> Try it now.
works!
I created an issue to track the remaining work to pass the endpoint
type thru the api,
http://github.com/Vagabond/OpenACD/issues/issue/10
but your fix allowed us to continue our testing so thank you!