Trunk monitoring

  1. 12 years ago

    Hello everybody,

    I'm using new FOP2 versión (2.26) and I’m getting some problems monitoring SIP trunks. I’ve installed FOP2 in a 1.8 Asterisk box which is used in a Call Center. This call center use a Dialer for outgoing calls so the calls are generated by chan_locals.

    My problem is that when monitoring the SIP trunk they used for outgoing calls I can’t see the detailed information (channel name and callerid) of the calls generated through chan_locals unless I run a “module reload” command in Asterisk. Once I do the reload I can see the detailed information of all the established channels but after some time the trunk only show information regarding calls generated from chan_sips. It looks as it doesn’t refresh the information from calls bridged to chan_locals.

    Is there any way to make it work without reloading Asterisk modules?

    Thanks

  2. admin

    10 May 2012 Administrator

    Hi

    Chan_locals are not real channels, you cannot monitor a chan_local in a consisten manner at all. This is not a fop2 fault, is the way asterisk works and how chan_locals where designed.

    You are not giving specifics, but you do not say HOW are you using chan_locals, if you are not doing it already, you might want to add a /n suffix so the local channel persist while the real channel lives too.

    A chan_local is destroyed as soon as the real channel is fired if you do no tuse the /n suffix

    Another thing to note if that if you use /n, then you will have an overpopulation of channels in asterisk itself..

  3. Hi,

    The dialer dials through an AMI ORIGINATE which CHANNEL is local/destination_number@outgoing_context/n, and outgoing_context do a Dial(SIP/siptrunk/destination_number).

    Sorry if my explanation wasn't right but I'm not saying that this behavior is a FOP2 fault, just don't know why when I reload Asterisk modules I can see the detailed information of all siptrunk channels but as these channels “dies” (calls finish) new ones don’t appear unless we reload Asterisk modules again. Just want to know if is there any way to make FOP2 show detailed information from all channels without reloading Asterisk modules.

    Thanks

  4. admin

    11 May 2012 Administrator

    No need to apologize, I just needed a little more information to try to figure out things. You are using the /n suffix and it does not work, so the other option is to NOT use it and see if fop2 behavior changes in the trunk button.

    If you see status after a reload, it is because the information was gathered via the AMI status command, but that command is only fired on fop2 startup or reload, from there on, fop2 relies on regular AMI events like Newchannel, newstate, etc, and maintains its own event machine. If you do not see status "live" it is because there are missing events, or some mix up in events and their order due to the infamous masquerading and local channels.

    Be sure you have "all" both in read and write in /etc/asterisk/manager.conf , and that you are not using eventmask or eventfilters and try that way. We do not want ANY event to be filtered for whatever reason. (Possible reasons are: using trixbox patched asterisk 1.6.phonecore-nonsense that is buggy, use of eventfilters in manager.conf, use of event_mask in fop2.cfg, etc).

    If the problem is not missing events but a consequence of masq/locals , then you might want to try removing the /n suffix.

    One important thing to note, remember that currently trunk buttons will show only bridged calls (leg A linkded to leg B). Calls within an application (Leg a -- Application (ivr, voicemail, whatever), do not show on the trunk detail list up until de call is linked/bridged to another channel.

    Finally, not sure exactly what is your need for monitoring those trunk channels, but you can configure a trunk as an extension button (manually), that way you can see non bridged calls while they are being dialed/received. That would be another option, not configure the trunk as trunk but as an extension. Some users want to monitor individual dahdi channels for their trunks, and they configure them that way.

    Best regards,

or Sign Up to reply!