internal of ecallmgr

[zhi sun]

Hi guys,

I am currently jumping into the ecalmgr source code. Since it is my first time to go through the erlang source code, it might be time consumed to fully understand the internal logic of ecallmgr.

It would be appreciated if you can light the way to explore the ecallmgr (as well as the freeswitch.erl).

For example:
- what does the ecallmgr_call_control.erl?

- what does the ecallmgr_fs_nodes.erl? i am confused about the comment of this file:
%%%
%%% When connecting to a FreeSWITCH node, we create three processes: one to
%%% handle authentication (directory) requests; one to handle route (dialplan)
%%% requests, and one to monitor the node and various stats about the node.
%%%

- how many dedicated services in ecallmgr, and how they interacted each other?

I have known that the FS - ecallmgr - MQ, according to what the james and stephen have said before. But i want to get more details about the internal of ecallmger :)

thanks in advance
-zhisun

[James Aimonetti]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There are a lot of components to ecallmgr. It has grown more
organically than other pieces of the stack, so things are not as
tightly contained as we might like (though its getting better with
each release).

That said, here's a basic overview to hopefully get you going.

ecallmgr_fs_nodes is the manager of adding/removing connections to
mod_erlang_event C-nodes. When we connect to mod_erlang_event, we bind
to it in a couple different processes:

1. ecallmgr_fs_node -> monitors the FreeSWITCH node itself, binds to
some event types (CHANNEL_CREATE, CHANNEL_DESTROY, some CUSTOM
variations, etc).

2. ecallmgr_fs_authn, ecallmgr_fs_route -> these bind to directory and
dialplan events, similar to mod_xml_curl. So when FreeSWITCH receives
a REGISTER or non-ACL INVITE, FreeSWITCH sends a directory request
proplist to ecallmgr_fs_authn, which converts the request into the
authn_req AMQP request. The response is received off AMQP and
converted to directory XML for FreeSWITCh to use.
Similarly, ecallmgr_fs_route receives dialplan requests. Generally
speaking, responding whapps just ask ecallmgr to park the call. We do
a three stage process to determine what whapp "wins" the route
request: ecallmgr_fs_route sends out a route_req; route_resps are sent
back; the first resp to be accepted by FreeSWITCH gets a route_win
payload sent back directly to it. In that payload contains the AMQP
queue of the controller for the call.

Now, we have a call that has come in. This is where
ecallmgr_call_events and ecallmgr_call_control come in.
ecallmgr_call_events binds to FreeSWITCH for the call, meaning all
call events related to the UUID are sent to ecallmgr_call_events. This
process (one per call) converts the proplist into call_event AMQP
payloads. This is how other listeners can know where the call is and
what the caller is doing (DTMF presses, etc).

ecallmgr_call_control maintains a queue of commands to run on the
channel. In the route_win payload from above, the Control-Queue is the
AMQP queue of the ecallmgr_call_control process. So, if I win the
route and publish a "answer" AMQP JSON payload, I will publish it to
the targeted exchange using the Control-Queue as my routing key. It is
possible to share the Control-Queue with others, but its up to the
application to do the sharing.
ecallmgr_call_control is also a consumer of call events (published by
ecallmgr_call_events). It uses the CHANNEL_EXECUTE and
CHANNEL_EXECUTE_COMPLETE events to determine when to forward its
command queue.

On top of ecallmgr_route_req, there's also an ecallmgr_authz_req (run
concurrently with ecallmgr_route_req). Authorization is optional for a
call, but when turned on, this module publishes an authz_req and
expects and authz_resp in return. If the call is authorized, the
module sends an authz_win to whichever process sent the authz_resp
first. See the jonny5 whapp for using the authz features (jonny5, from
the movie Short Circuit).

freeswitch.erl is just a wrapper module over interacting with
mod_erlang_event. Because its a C-node, there are several registered
processes it emulates which we send various types of messages to in
order to get things done. Its provided along with mod_erlang_event as
a convenience module.

ecallmgr_fs_pinger processes get started when we lose connection to a
known FreeSWITCH node, and will ping it periodically until the
connection is re-established or you manually rm_fs_node the node. We
tear all associated processes (ecallmgr_fs_route, authn, etc) down
when we lose the connection; when pinger successfully pings the
FreeSWITCH node again, all of the processes are started back up fresh
(with some syncing done between FreeSWITCH and ecallmgr in case it was
a temp network outage).

ecallmgr_fs_resource mostly listens for origination requests (click to
call, outgoing fax, etc).

ecallmgr_conference_listener helps manage conference requests (finding
which FS server a conference was started on, so a caller can be placed
in it), and ecallmgr_conference_command is the command queue for the
conference (like ecallmgr_call_command, but with conference-specific
AMQP APIs).

ecallmgr_shout and ecallmgr_media_registry help with playing URLs.
They send media_req out, and receive media_resps with HTTP URIs of the
.wav/.mp3 files. We then use mod_http_cache and playback to fetch,
cache, and play the file locally from the FreeSWITCH server.
ecallmgr_shout handles the recording of calls (voicemail) and having
FreeSWITCH stream the resulting file to this ecallmgr_shout process.
This process then can stream the media file up to BigCouch. This
module will probably be going away, as we can now PUT/POST directly
from FreeSWITCH using mod_http_cache (http_put). We currently do this
with storing received faxes; it will be trivial to change the store
recording command to do the same (just need the time).

ecallmgr_registrar keeps a local cache of successful registrations
(though the running registrar whapps are generally the canonical
authorities), used when sending information to known devices (like
bridge commands).

The rest are supervisors or utility modules. You can use appmon to see
the layout of the supervisor tree.

Hope that helps you navigate the code a bit.

James

- --
James Aimonetti
Distributed Systems Engineer / DJ MC_

2600hz | http://2600hz.com
sip:ja...@2600hz.com
tel: 415.886.7905
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQBQfWAAoJENc77s1OYoGg75wH/ReBd/wip6m1Vcz8nrDLCeQE
nagf+w4SrNa6k2tpjM99Ep11JVJfo4udenogAFDA3HJAuiqysPDFy60EmoiX0rAi
KlHGSAEm6N3BHeGmRmPiSepsozUCC1o9hIxpxu+07JAaaR7RH1abCLF0js32TPI8
/Ghhb6bW7BHu2j3QGjljJviCEpSI5jA27+JroNivKhrRypnpd7YsKtQBOKywz0zp
nx6hlPU2Gynvs+0J+Lc+qFvD3+09heOtzE7zUOjg9/op47IWDDrv3SfYznjAmyN3
HigTKkzVcsAV3z+O44a5HXNBkLIP5P7Rk4azbYIBtgwLdoDmfxQVcj3f56lEQxY=
=8PO6
-----END PGP SIGNATURE-----

[Alejandro Recarey Llerena]

Thank you Zhisun for a great question, and James for a great answer.

[zhi sun]

Jamers, thank you for the great guide. Your answer has exceeded my expectation from 2600hz-dev!

2012/7/17 James Aimonetti <ja...@2600hz.com>

[James Aimonetti]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Zhi,

Wanted to check in with how things were going for you. I've put my
previous mail up on the wiki:
https://2600hz.atlassian.net/wiki/display/docs/Overview+of+ecallmgr

I plan to break it down into bullet points per useful module, and
start to describe how the modules interact, and just generally make it
a useful architecture page.

It would be quite nice if you could contribute to this page during
your learning. We've been bogged down in the weeds so long that having
someone take a look at the code as a whole, for the first time, will
provide some great perspective. We know why the code has evolved the
way it has, but sometimes you lose the 10,000 meter perspective on how
it all goes together and miss some inconsistencies.

James

On 07/17/2012 01:41 AM, zhi sun wrote:
> Jamers, thank you for the great guide. Your answer has exceeded my
> expectation from 2600hz-dev!
>
> 2012/7/17 James Aimonetti <ja...@2600hz.com>
>

iQEcBAEBAgAGBQJQB5odAAoJENc77s1OYoGgjJkH/ji3ZAzPdmaONeZMEejeNXSp
DP8VTDxOXHyMOWdXfJAXepiFSyto1BTKgg1zpjOaSkKvsp7NI3HaIpbylbWLQumd
V6hhNdXQiAqyhv5GVCoSvTioN+P06S1JZSKex19hcSmqmvQdMRjBzfBWXjc+KVBl
JkMaXPY8IqoqpsXZhTQH2L2kIxmARfpxCOf3wUij5hjxTCHdsLP5OaJ3PBmbZgSq
GDATTz1YDm64IBw4+gSFFVp9+Lz3fErXL/QHPOuSNZ5+dj9af40OeEjO2mN4uEM8
NM5WTeOZTmAXQtw+8SZv6i/t8pYRt9XQctFhwoBMxPH35ewesXuGdNj8DWuNzuo=
=rZ8z
-----END PGP SIGNATURE-----

[zhi sun]

Hi James,

It is my honor to  have change to make some contribution to 2600hz!

Just want to know how to do, or how to modify the wiki page myself? I cannot find a way on the wiki.

I am involved in an emergence project recently, so might not be so active in 2600hz project for a while, but i am sure to keep it moving forward ...

If i encountered any problem/question when going through the source code, is it OK to simply send message to this group or in other ways?

Thanks,
-zhisun

2012/7/19 James Aimonetti <ja...@2600hz.com>

[Darren Schreiber]

Send me your wiki username off-list and I will grant edit access.

--

Darren Schreiber

CEO / Co-Founder

 visit: www.2600hz.com

 sip:dar...@2600hz.com

 tel: 415-886-7901

[zhi sun]

iamsyt
sunzhi...@gmail.com

2012/7/20 Darren Schreiber <dar...@2600hz.com>

[zhi sun]

Hey James,

i am planing to get back to this area again.

when I trace the debug log of the process of starting ecallmgr, i notice there are so many rabbitmq connections establish information, is it rabbitmq connection pool? could you please explain a little bit more about this?

thanks,
-zhisun

2012/7/19 James Aimonetti <ja...@2600hz.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[James Aimonetti]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Exactly right. Because most processes are short-lived, and need a
request/response messaging system, we found it less expensive to
create a pool of AMQP workers
(lib/whistle_amqp-1.0.0/src/wh_amqp_worker.erl) to handle the AMQP
side of things, and the short lived processes treat it like a blocking
function call, rather than the processes creating an AMQP channel and
queue each, publish one message, consume maybe a handful of messages,
and tear down the channel/queue.

I think the default is 200 workers, but you can edit that in
ecallmgr/src/ecallmgr_sup.erl

There is also a pool on the whapps side, in
whistle_apps/src/whapps_util.erl and whistle_apps/src/whistle_apps_sup.erl

Hope that helps,

James

On 08/28/2012 08:38 AM, zhi sun wrote:
> Hey James,
>
> i am planing to get back to this area again.
>
> when I trace the debug log of the process of starting ecallmgr, i
> notice there are so many rabbitmq connections establish
> information, is it rabbitmq connection pool? could you please
> explain a little bit more about this?
>
> thanks, -zhisun
>
> 2012/7/19 James Aimonetti <ja...@2600hz.com>
>

Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQPO1kAAoJENc77s1OYoGgEbAH/0c+I+0qdUK2mso2gPml7GGM
AhqW8jVyTrcNhTen+aoR2SNDd9LcmjSLPRWdcfzbX3hCfH3Rhn28yaz9UiKd83xR
qTHvxEvRxedIsUetnklND4jnX5u11B7o8YWwR+KXUjz0SsAA+12MUU6ZWp/QLp9E
GKbhAFnwbQsHtCrbsKSoO8pOD4jl7KDym0+jAm4zmeigtv6T9QeWRAM7iy9FskZH
uUoOSLjcYBRMWl43ovAMDptf3jzbN4fjO3eLB+KrrDMb9Nkavf/ziwQx5GH0GIQS
fXeRXp0ExoXVjCwMeTOLmSpjtZQhvrAnUq1OQpUvYmP7RDBHvZ9JQt5DdGYZ9Pg=
=GouJ
-----END PGP SIGNATURE-----

[zhi sun]

James, thank you for your reply!

there is another question about conference: does kazoo support conference happen across multiple FS?

let me explain, there are two users A and B registered to FS1, while another user C registered to FS2, how can the users A,B and C make a conference together?

i have a look at the ecallmgr_conference_listener and ecallmgr_conference_command, but cannot find the answer to this issue.

best regards?
-zhisun

2012/8/29 James Aimonetti <ja...@2600hz.com>

[James Aimonetti]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zhisun,

Yes, conferences are supported across FreeSWITCH boxes.

First, what FreeSWITCH box a device registers to doesn't affect
anything about what that device can/can't do later on. We store the
registration information (particularly the Contact header) in Kazoo,
so any call that comes in for that device can be bridged to it,
regardless of the FreeSWITCH box handling the call.

Conferences are controlled primarily by the conference whapps
(whistle_apps/apps/conference), and the ecallmgr-level conference
modules support that whapp. The conference whapp determines if a call
coming in for a conference is on the same FreeSWITCH box as the
conference. If so, it enters the call into the conference. If not, I
believe it bridges the call to the conference's FreeSWITCH server,
answers that bridge, and connects the bridged leg to the conference.

So A calls in, we create A1 and join it to the conference.

[FS1]-A1-[FS2]--Conference
|
A

We have a call_move feature coming that will re-INVITE the call leg so
we can move the leg to the conference FreeSWITCH server and join it
locally, rather than waste a channel bridging the two FreeSWITCH
servers together.

Hope that helps.

On 09/10/2012 07:14 AM, zhi sun wrote:
> James, thank you for your reply!
>
> there is another question about conference: does kazoo support
> conference happen across multiple FS?
>
> let me explain, there are two users A and B registered to FS1,
> while another user C registered to FS2, how can the users A,B and C
> make a conference together?
>
> i have a look at the ecallmgr_conference_listener and
> ecallmgr_conference_command, but cannot find the answer to this
> issue.
>
> best regards? -zhisun
>
>
>
>
> 2012/8/29 James Aimonetti <ja...@2600hz.com>
>

iQEcBAEBAgAGBQJQThOwAAoJENc77s1OYoGgyzMH/3GtO8/M5EwmDvxi5Qk8hh0s
gsuAJjLdJHIS4Zw6r83xJPbQH1E3FiSCvS8gdjApks9kcmOqYJ7TQ/0JQacai8Pc
FntM4Cyh8E+/wW/1tyQ48DvYB8nLhHfDvyXbo9erDWdFW3C3U0tVd4eH01nYMMDU
tN1hnn4FuA12hDgAACFI9NGXc4tmSvAj6gfwMAUDsl4SL2KRIn8hrTi6p+WKm4q+
zAVKZ4L5vMAqcIU0Yb5P8hfi7zcdTvbYwWNMKHDSG2Qw8syQ/JPBtsLbmXoczKMG
EAonAG3IcorIvEe/Nb5qE8k4JkfkR4MVFFHOheMs0dUq4f4Rt0a54veNkfd4in4=
=Kq0p
-----END PGP SIGNATURE-----

[zhi sun]

James, thank you very much!

it might take me some days to trace the code to understand what you said.

but i can image that the volume of the members in a conference is limited by the HW/SW resource of the FS (on which running the conference), if so, how to handle the conferences with large volume members, for example, 50000 users?

I ask this question, because i have seen that some voice communication systems support this kind of situation, (ie, YY), as an event happens in real world, there are more than 60000 users take party in the same channel, as conference. I believe that a standalone FS cannot do such thing. 

there is nothing, just want to talk about the tech possibility:)

best regard
-zhisun

2012/9/11 James Aimonetti <ja...@2600hz.com>

[Darren Schreiber]

We have seen this application/use case before and have achieved it ourselves. It is done by bridging conference bridges on different FreeSWITCH servers together.

That's not what the current code is intended for but you could do a reasonably minor modification to what's already there to create this ability – just bridge the conference bridges together and write some code to randomly distribute people into two servers. And done :-)

The eventing systems are already tied together so it should be easy to manage.

- Darren

From: zhi sun <sunzhi...@gmail.com>
Reply-To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Date: Tuesday, September 11, 2012 1:16 AM
To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Subject: Re: internal of ecallmgr

[zhi sun]

Darren, thank you for your quick response, what you said has addressed my issue!

thanks,
-zhisun

2012/9/11 Darren Schreiber <dar...@2600hz.com>