Problem with devstate updates / dialplan

FreePBX Development
1

CentOS 5.x, FreePBX 2.9, Asterisk 1.8.14.1

I’ve been working on distributed device states via XMPP and have 99% successfully hacked it in. Currently, it works as I need:

  • place a call and the custom dev state is distributed via jabber
  • once the call is complete the custom dev state is distributed via jabber

Example:

-- Executing [s@macro-dialout-trunk:18] GotoIf("SIP/200-00000019", "0?bypass,1") in new stack
-- Executing [s@macro-dialout-trunk:19] GotoIf("SIP/200-00000019", "0?customtrunk") in new stack
-- Executing [s@macro-dialout-trunk:20] Set("SIP/200-00000019", "DEVICE_STATE(Custom:JS-DAHDI/g0)=INUSE") in new stack
-- Executing [s@macro-dialout-trunk:21] Dial("SIP/200-00000019", "DAHDI/g0/1555,300,") in new stack
-- Called DAHDI/g0/1555
-- DAHDI/1-1 answered SIP/200-00000019
-- Executing [h@macro-dialout-trunk:1] Macro("SIP/200-00000019", "hangupcall,") in new stack
-- Executing [s@macro-hangupcall:1] Set("SIP/200-00000019", "DEVICE_STATE(Custom:DAHDI/g0)=NOT_INUSE") in new stack

== Extension Changed DAHDIg0[ext-local-custom] new state Idle for Notify User 300
== Extension Changed DAHDIg0[ext-local-custom] new state Idle for Notify User 301
– Executing [s@macro-hangupcall:2] GotoIf(“SIP/200-00000019”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,4)
– Executing [s@macro-hangupcall:4] Hangup(“SIP/200-00000019”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘SIP/200-00000019’ in macro ‘hangupcall’
== Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on ‘SIP/200-00000019’
– Hanging up on ‘DAHDI/1-1’
– Hungup ‘DAHDI/1-1’
== Spawn extension (macro-dialout-trunk, s, 21) exited non-zero on ‘SIP/200-00000019’ in macro ‘dialout-trunk’
== Spawn extension (from-internal, 1555, 5) exited non-zero on ‘SIP/200-00000019’

That’s GREAT however, when a call is placed and the line is hung up before the device enters the answered state, the custom devstate is not triggered to set NOT_INUSE.

Example:

-- Executing [s@macro-dialout-trunk:18] GotoIf("SIP/200-00000018", "0?bypass,1") in new stack
-- Executing [s@macro-dialout-trunk:19] GotoIf("SIP/200-00000018", "0?customtrunk") in new stack
-- Executing [s@macro-dialout-trunk:20] Set("SIP/200-00000018", "DEVICE_STATE(Custom:DAHDI/g0)=INUSE") in new stack

== Extension Changed DAHDIg0[ext-local-custom] new state InUse for Notify User 300
== Extension Changed DAHDIg0[ext-local-custom] new state InUse for Notify User 301
– Executing [s@macro-dialout-trunk:21] Dial(“SIP/200-00000018”, “DAHDI/g0/1555,300,”) in new stack
– Called DAHDI/g0/1555
– Hanging up on ‘DAHDI/1-1’
– Hungup ‘DAHDI/1-1’
== Spawn extension (macro-dialout-trunk, s, 21) exited non-zero on ‘SIP/200-00000018’ in macro ‘dialout-trunk’
== Spawn extension (from-internal, 1555, 5) exited non-zero on ‘SIP/200-00000018’
– Executing [h@from-internal:1] Hangup(“SIP/200-00000018”, “”) in new stack
== Spawn extension (from-internal, h, 1) exited non-zero on ‘SIP/200-00000018’

I’ve plugged the call into various places in core/functions.inc.php to no avail; macro-dialout-trunk, macro-hangupcall, macro-hangupcall-custom, and others. I can’t for the life of me figure out the magic.

Here is the current macro-hangupcall from “dialplan show”

===================================================
[ Context ‘macro-hangupcall’ created by ‘pbx_config’ ]
‘s’ => 1. Set(DEVICE_STATE(Custom:${OUT_${DIAL_TRUNK}})=NOT_INUSE) [pbx_config]
2. GotoIf($["${USE_CONFIRMATION}"="" | “${RINGGROUP_INDEX}”="" | “${CHANNEL}”!="${UNIQCHAN}"]?theend) [pbx_config]
[delrgi] 3. Noop(Deleting: RG/${RINGGROUP_INDEX}/${CHANNEL} ${DB_DELETE(RG/${RINGGROUP_INDEX}/${CHANNEL})}) [pbx_config]
[theend] 4. Hangup() [pbx_config]
Include => ‘macro-hangupcall-custom’ [pbx_config]

It seems to me (yes I am a newb) that I need to add the call to the context “from-intermal”. I’ve tried adding from-internal-xfer because that’s the only context that contains Macro(hangupcall) but I’m missing something.

I’ve been working on this for a couple weeks now and I’m out of ideas. I’d really appreciate some help here. Hopefully this problem can be resolved!

2

I’ve tried a bunch of contexts to try and get the job done. [macro-hangupcall-custom] seemed logical but even though it’s included from [macro-hangupcall], it is not part of the dialplan when the calling party hangs up BEFORE the call is answered. I found the correct context by running:

“dialplan show h@from-internal”

When I modded from-internal-noxfer-additional to call the Set statement before the Hangup, I got the state updated the way it needs to be. It seems that in this case, it has to be in from-internal-noxfer-additional. If the call goes through and is answered, the Set statement in macro-hangupcall does the job.

I’m feeling pretty good about all this now EXCEPT I cannot see how to modify from-internal-noxfer-additional or where it gets generated. I’m guessing it’s there in functions.inc.php but it’s elusive at best!

Of course, there may be a better way but I can’t see it so far. I’m certainly open to suggestions!

I’ll PM you. Thanks.

3

Area51,

sorry, things can sometimes get lost in the forums as a lot of stuff comes through here and if a day or two is missed it often doesn’t get seen, I was personally gone for a long weekend so quite behind.

As far as the XMPP is concerned, I’d be interested to chat with your work and what you’ve found. It’s an area that we are interested in understanding better but none of the devs have had the cycles yet to get it going, so if you’ve got some stuff up that would be helpful.

It was my understanding that if setup “right” it would be possible to see the state of extensions on remote systems without having to setup custom states. That was one of the very appealing potentials since, if you have to manually track the state of an extension, you will continuously have issues like you describe which can be problematic to address.

I’ll try to make sure I’m logged into the IRC channel as I have not been for a little while, or you are also welcome to PM me and we can try to sync up.

4

Thanks, I am more of a forum guy than IRC. I did ask a couple questions on #freepbx the other day and got some response but my work schedule makes it kinda hard to stay in the conversation. Maybe I’m just old :smiley:

I finally found the context that I needed. Adding the call to [from-internal-noxfer-additional] fixes the problem. I’m now trying to figure out how that’s generated.

I’m going to continue to work on this before contacting anyone. Once it’s done, I’ll file a feature request with patch. So far I’m able to see status for Gvoice, DAHDI and SIP trunks. All using Custom states.

Jabber does report ALL states, not just custom states. I have not figured out how to register them so far.

I’ll hit up IRC #freepbx-dev later on.

Thanks, Andrew

5

Andrew,

please to get in contact even if you are going to plow through on your own.

I’m particularly interested in your progress on viewing states of other extensions “auto-magically” or to the extent it is not that “auto-magical” then what is involved.

Some examples that would be extremely useful are for examples queue members at remote sites so that their state could be visible to the queue. Other examples are simply figuring out what would be needed to setup a BLF button on a reception console that is a remote PBX extension and how that could be easily monitored on the ‘local’ PBX.

So thanks for now on any light you can shed in your testing.

As far as the from-intenral-noxfer-additional context, that is the primary context that excludes almost everything auto-generated with a few exceptions, such as no intercom contexts to avoid a transfer being accidentally sent to an intercom situation. Modules simply add their contexts to that context, you would not want to put something directly in that context other than another context that contains anything you might be looking to add. If you need to add something to an existing context, such as the macro-hangupcall context, then you need to splice it in from another module which is “a bit tricky” and not well documented but once you see some examples then it becomes fairly straight forward.

6

There really aren’t any developers hanging out here. A few pop in from time to time but you can’t count on it.

I would talk to Tony about support, the support service is also not primarily for custom programming and is not staffed by programmers (it would be far more expensive).

Have you tried hanging out in the FreePBX IRC channel? Get to know the developers?

7

Every question I’ve asked on this forum has gone largely ignored. Is this the kind of thing I need to step up and get paid support for?

8

Area51,

your problem of trying to use macro-hangupcall-custom is simply a common mis-understanding of how Asterisk processes included contexts. Doing what you are describing could have subtle negative consequences.

If you need something in the macro-hagupcall context then you are going to have to “splice” into that context from a new or existing module so that it get’s executed. That is usually the correct place if you really need to trap something that could happen throughout the dialplan upon a hangup.

9

What can I say, this is the first time I’ve dug into the code!

I’m checking to see what can be done automatically. jabber status messages are flying around on all the servers. The more I work with Custom Devstates the more I see major rewriting. I’ll keep you posted.

10

Area51,

I’ve found that the Custom Devstates are very useful for various features which don’t have the problem you are having.

If you are trying to create ‘state’ information on something that is dynamic in nature and that Asterisk is already tracking, then I would try to do it by simply creating a hint against that device assuming this ‘auto-magical’ capability exists to simply transmit such hints across XMPP which was my understanding as I mentioned earlier.

As mentioned, feel free to ping me on #freepbx-dev on the IRC and we may be able to quickly get to a good solution or otherwise clarify some of the issues you are running into.

11

Look for me on IRC tomorrow. what time zone are you in?

12

Area51,

Pacific Time Zone, Seattle …

13

I’m east coast. I’ll be on there after 2pm EST. saysocomm

I’ve narrowed everything down and have two patches for the dialplan. One touches core/functions.inc.php, the other touches extensions_additional.conf (because I can’t find where to autogenerate what’s needed).

14

Oh well, IRC just doesn’t work for me. :-/