[Home]

Summary:ASTERISK-05630: [branch] Devicestate for chan_local and parking
Reporter:Olle Johansson (oej)Labels:
Date Opened:2005-11-17 12:49:30.000-0600Date Closed:2006-06-26 11:45:28
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_local
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) metermaid-1.2.7.1.txt
Description:This patch adds a devicestate function to chan local that merely reports whether or not an extension exists. It also adds a metermaid function to parking in res_features:

chan_local registers as a metermaid, res_features alerts every time a call is parked or unparked (extension appears and disappears in the parkedcalls context).

Now, if you add a hint that points to local/701@parkedcalls and subscribe to that in SIP, you will immediatelly see when a call is parked on that extension!
Comments:By: philipp2 (philipp2) 2005-11-21 18:05:12.000-0600

Yeah - immediately makes me think of dynamic MeetMe rooms as next target... ;->

By: Olle Johansson (oej) 2005-11-22 02:02:36.000-0600

That's an interesting thought. However, they don't use dynamic extensions like the parking system so that requires a different kind of solution.

By: philipp2 (philipp2) 2005-11-22 08:07:16.000-0600

Allright, how about this:

* Creating & deleting extensions via either
** CLI "add/remove extension" (e.g. thru "asterisk -rx" or Manager API)
** Realtime extensions conf

* Employing regcontext= in sip.conf to add/remove the extension

This has the potential to replace the bristuff "app_devstate".



By: Olle Johansson (oej) 2005-11-22 08:46:04.000-0600

Realtime extensions would be really hard, since we get no notification from the database on changes...

Hooking up metermaids on adding/removing extensions via cli and/or manager is easier.

By: Rob (rob314) 2006-01-03 11:39:17.000-0600

Is a hint extension in the dialplan still necessary since it is created by default when 'parkhints=yes'.

I have this patch running but when I do a 'show hints', all of the parking spots are shown as "State:Unavailable" when no one is parked.  When someone is parked in the spot the state is "State:Idle".  Is the metermaid just reporting the wrong state number?

By: Olle Johansson (oej) 2006-01-03 11:59:24.000-0600

No, that's the right status. Have you tried with a SIP phone?

By: Rob (rob314) 2006-01-04 10:03:22.000-0600

Tried it on a SIP phone (Polycom 601 with Exp Mod) and once someone is parked in position 701 (for example) the icon on the phone screen changes from the block of dots (which I assume is the unavailable/unregistered icon) to the "buddy" icon which on a standard SIP hint, like a phone show that the user is registered and available for calls -- or in State: Idle.

When that parking spot is cleared the hint in Asterisk returns to "Unavailable" and must confuse the phone because then the phone's icon changes to a clock icon, which I assume means the extension is in-use.

At this point I see two things that can fix this.  It appears as I said earlier that Asterisk is not reporting the correct hint state to the phone/end-point.  


Parking spot state           Hint State              Phone State

empty (before parking)       unavailable             Unavailable or In-use

someone parked at 701        idle                    Idle

empty (after parking)        unavailable             In-use


Or in several cases I have had in the past, the phone isn't updating or doing what it is supposed to.  I am looking through the polycom configuration files to see if I can change how often Buddy Status/Presence gets updated.

I have tried several combinations of configuration.  Adding hint extensions in extensions.conf in addition to the ones that were created by res_features, but still get the same result.

By: Olle Johansson (oej) 2006-01-09 06:26:24.000-0600

Now moved to
http://svn.digium.com/svn/asterisk/team/oej/metermaids/

By: mike240se (mike240se) 2006-01-15 14:12:49.000-0600

this is great!  rob mentions using parkhints=yes, is that in 1.2.1??  I have never seen that.  I think I need your patch cause I would like to be able to assign one or two buttons on my snom phones for static parking spots that will light up the blf when that spot is in use so people can easily pick it up in a small office enviroment....

By: Rob (rob314) 2006-01-16 12:51:15.000-0600

Mike:  Yes, the "parkhints" I mentioned are added in with this patch.  From what I can tell that option creates the dialplan hints for the parking spots so that you can use your SIP client to subscribe to them.

I was testing this with a Polycom 601 with expansion modules and didn't have a whole lot of luck -- since the 601 only can watch 6 "buddies".  It also didn't report the status of the parking spot correctly (as described above).  I haven't had enough time to give it a shot with my snom in the test lab but once this feature can be tested by more people I think it will be a very valuable addition to Asterisk.

oej:  Have there been any updates with this since moving it to SVN?

By: mmckernan (mmckernan) 2006-01-30 04:01:39.000-0600

I have tested this patch on a Snom handset, and it appears to work OK. I will do further testing tomorrow.

However, in the subscribe context of the handset, you need to set up each parking lot manually:

exten => 701,1,ParkedCall(701)
exten => 701,hint,Local/701@parkedcalls

etc...

Otherwise when the handset sends its Subscribe request, Asterisk will reply 404 not found as the 701 extension does not exist. It only exists once someone is parked on the extension.

By: Jan-Peter Koopmann (jkoopmann) 2006-01-30 11:21:41.000-0600

Hi oej,

looks like a great patch. One "problem" though. Indeed when a parkingslot is empty, show hints gives me "Unavailable". At least SNOM phones display this with a steady shining LED on the phone though giving the impression that the parkingslot exists and is in use. Would "Idle" not make more sense for an empty parking-slot and "InUse" for a used parking slot?

By: Brian Homeyer (bigb) 2006-02-15 14:05:56.000-0600

Doesn't work with GXP2000's either.  Channel state is wrong to give any sort of response on the phone.  I am assuming that I'd need to change :

+ return AST_EXTENSION_UNAVAILABLE;
+ else
+ return AST_EXTENSION_NOT_INUSE;

to :

+ return AST_EXTENSION_NOT_INUSE;
+ else
+ return AST_EXTENSION_RINGING;

To get this to work, am I correct?

By: mike240se (mike240se) 2006-02-15 16:20:53.000-0600

that would make much more sense, if a user sees a steady light they will think its in use, idle and in use are much better than unavail and idle..

By: Brian Homeyer (bigb) 2006-02-15 16:23:10.000-0600

Unfortunately, the change I put above does not work as expected.  So I am in the process of going through the code for a "starting point".  First time I've actually checked the code out, so I was hoping someone here would give me a little start on where to look to change the status.

By: mjc (mjc) 2006-02-23 12:51:46.000-0600

I'd LOVE to see this patch working on my Snom 360!

Can someone help an svn newbie figure out how to test this patch? I've done the following:

svn checkout http://svn.digium.com/svn/asterisk/team/oej/metermaids asterisk
cd asterisk
make clean
make install

but I get this error:

asterisk.c: In function âmainâ:
asterisk.c:2209: error: âoption_dumpcoreâ undeclared (first use in this function)
asterisk.c:2209: error: (Each undeclared identifier is reported only once
asterisk.c:2209: error: for each function it appears in.)
make: *** [asterisk.o] Error 1

What am I doing wrong? (I have 1.2.4 installed and working fine, from the tar.gz).

- Mike

By: mjc (mjc) 2006-03-04 15:35:07.000-0600

OK, ignore my last note - I installed metermaid.txt as a patch over 1.2.4, and it works as described above. The SNOM 360 lights never light up, because of the IDLE / UNAVAILABLE issue. I tried editing

+ return AST_EXTENSION_UNAVAILABLE;
+ else
+ return AST_EXTENSION_NOT_INUSE;

like bigb, but changing these lines doesn't seem to change the behaviour (you still get IDLE or UNAVAILABLE)!

bigb, have you made any progress? Anyone else have any clues?


- Mike

By: mike240se (mike240se) 2006-03-05 00:23:19.000-0600

Well I pulled these as the possible states from chan_sip.c, I wanted to see what it normally uses.  

AST_EXTENSION_RINGING
AST_EXTENSION_INUSE
AST_EXTENSION_BUSY
AST_EXTENSION_UNAVAILABLE
AST_EXTENSION_NOT_INUSE

Why not use "Not_inuse" for no call and "inuse" for a parked call.  Ringing would be good if you want it to blink when there is a call parked.  Unavailable will cause the light to be on all the time, not sure about busy.

I am going to try and modify the patch tonight.

By: mike240se (mike240se) 2006-03-05 00:32:01.000-0600

Just a thought, i assume "unavailable" was used to light up the button when a call is parked, but why not use "inuse" if the snom phone thinks the extension is unavailable, pressing the button will not do anything, meaning you cant pick up the call.  I am not sure about this but just a thought.

By: Olle Johansson (oej) 2006-03-05 01:58:30.000-0600

There's a general problem with blinking lights on SNOM phones that I'm looking into, but that is a separate issue.

By: Olle Johansson (oej) 2006-03-05 06:05:36.000-0600

Moving patch to branch "oej/metermaids-trunk".

The old branch collapsed and was way out of sync with trunk.

By: mjc (mjc) 2006-03-05 06:28:41.000-0600

mike240se,

The problem is HOW do we change the reported device state?

I changed chan_local.c to read:

   if (!res)
       {
       ast_log(LOG_DEBUG, "returning: %d\n",AST_EXTENSION_UNAVAILABLE);
       return AST_EXTENSION_UNAVAILABLE;
       }
   else
       {
       ast_log(LOG_DEBUG, "returning: %d\n",AST_EXTENSION_INUSE);
       return AST_EXTENSION_INUSE;
       }

but instead of "In Use", "show hints" reports "Idle", even though the above bit of code returns the right values (In use = 1, Unavail = 4, whereas Idle = 0):

 == Parked IAX2/64.26.157.230:4569-7 on 701. Will timeout back to extension [internal] 602, 1 in 90 seconds
Mar  5 07:21:42 DEBUG[18800]: chan_local.c:126 local_watcher: Got notification of state change for 701@parkedcalls    -- Playing 'digits/7' (language 'en')
Mar  5 07:21:42 DEBUG[18756]: chan_local.c:146 local_devicestate: Checking if extension 701@parkedcalls exists (devicestate)
Mar  5 07:21:42 DEBUG[18756]: chan_local.c:155 local_devicestate: returning: 1
Mar  5 07:21:42 DEBUG[18756]: chan_local.c:146 local_devicestate: Checking if extension 701@parkedcalls exists (devicestate)
Mar  5 07:21:42 DEBUG[18756]: chan_local.c:155 local_devicestate: returning: 1
   -- Music class default requested but no musiconhold loaded.
   -- Music class default requested but no musiconhold loaded.
   -- Music class default requested but no musiconhold loaded.
show hints

   -= Registered Asterisk Dial Plan Hints =-
  602                 : SIP/mary-office       State:Idle            Watchers  0
  601                 : SIP/mjc-test          State:Idle            Watchers  0
<snip>
  703                 : Local/703@parkedcall  State:Unavailable     Watchers  0
  702                 : Local/702@parkedcall  State:Unavailable     Watchers  0
  701                 : Local/701@parkedcall  State:Idle            Watchers  0
----------------
- 22 hints registered
 == IAX2/64.26.157.230:4569-7 got tired of being parked
   -- Hungup 'IAX2/64.26.157.230:4569-7'
Mar  5 07:22:07 DEBUG[18757]: chan_local.c:126 local_watcher: Got notification of state change for 701@parkedcallsMar  5 07:22:07 DEBUG[18756]: chan_local.c:146 local_devicestate: Checking if extension 701@parkedcalls exists (devicestate)
Mar  5 07:22:07 DEBUG[18756]: chan_local.c:150 local_devicestate: returning: 4
Mar  5 07:22:07 DEBUG[18756]: chan_local.c:146 local_devicestate: Checking if extension 701@parkedcalls exists (devicestate)
Mar  5 07:22:07 DEBUG[18756]: chan_local.c:150 local_devicestate: returning: 4

Any suggestions? I've obviously overlook something.

By: Olle Johansson (oej) 2006-03-05 07:19:43.000-0600

When you park a call, the devicestate will change. Only then.

By: mjc (mjc) 2006-03-05 07:40:02.000-0600

oej,

In the debug output above, I park a call on 701. The debug output from chan_local.c (which I added) shows that local_devicestate returns AST_EXTENSION_INUSE, but running "show hints" from the CLI reports "Idle", in this parked state. They disagree, in other words.

By: mjc (mjc) 2006-03-05 12:14:33.000-0600

I'm making some progress. I think the patch is confusing "AST_EXTENSION" and "AST_DEVICE" flags. Check out this cleverness:

AST_DEVICE_UNKNOWN   0
AST_DEVICE_NOT_INUSE   1
AST_DEVICE_INUSE   2
AST_DEVICE_BUSY   3
AST_DEVICE_INVALID   4
AST_DEVICE_UNAVAILABLE   5
AST_DEVICE_RINGING   6

AST_EXTENSION_REMOVED = -2,
AST_EXTENSION_DEACTIVATED = -1,
AST_EXTENSION_NOT_INUSE = 0,
AST_EXTENSION_INUSE = 1 << 0,
AST_EXTENSION_BUSY = 1 << 1,
AST_EXTENSION_UNAVAILABLE = 1 << 2,
AST_EXTENSION_RINGING = 1 << 3

Totally different flags. Sigh. Anyways, if I use:

   if (!res)
       {
       ast_log(LOG_DEBUG, "returning: %d\n",AST_DEVICE_UNAVAILABLE);
       return AST_DEVICE_UNAVAILABLE;
       }
   else
       {
       ast_log(LOG_DEBUG, "returning: %d\n",AST_DEVICE_INUSE);
       return AST_DEVICE_INUSE;
       }

then "show hints" seems to report the proper status. (That is, I'm using DEVICE instead of EXTENSION flags). The SNOM lights aren't working yet; that's next!

- Mike

By: mjc (mjc) 2006-03-05 14:43:39.000-0600

OK, I've taken this patch to the next level, but some more work is needed. The "metermaid.txt" patch should have these corrections:

1) Not sure if this is important - change capitalization:

+   ast_device_state_changed("local/%s@%s", exten, context);
to
+   ast_device_state_changed("Local/%s@%s", exten, context);

2) Real important - change:

+   if (!res)
+       return AST_EXTENSION_UNAVAILABLE;
+   else
+       return AST_EXTENSION_NOT_INUSE;

to

+   if (!res)
+       return AST_DEVICE_NOT_INUSE;
+   else
+       return AST_DEVICE_RINGING;

or something similar. This will make things work correctly, at least when using "show hints" from the CLI. However, I am having some trouble making the SNOM lights work - there is something funny going on in the extensions / contexts. As suggested by mmckernan, you need to add something like:

exten => 701,1,ParkedCall(701)
exten => 701,hint,Local/701@parkedcalls

in the handset context, to make the lights active. (This is with parkhints off). BOTH lines are needed. This makes the light flash when there is a parked call. However, pressing the button doesn't connect me to the parked call. I'm not sure why. Perhaps someone else can do some experimenting to see what magic combination of "includes", contexts, and hints are needed :-)

- Mike

By: mike240se (mike240se) 2006-03-05 14:53:14.000-0600

What device state are you using?  Blinking means ringing, it will not dial a phone that is ringing, use inuse so the light is just on, that way it will call what its mapped to.  the phone decides if it should allow you to dial based on the status of the device, unavailable and ringing will not let you press the button to call it.  I believe inuse should allow you to call, i dont have a snom with me, but i am going to test this on a gxp-2000.

By: mjc (mjc) 2006-03-05 17:01:16.000-0600

mike240se:

I'm using AST_DEVICE_NOT_INUSE and AST_DEVICE_RINGING, as listed above. Please try whatever combination of AST_DEVICE_xxxxx you like, and let us know if it works! (Just avoid AST_EXTENSION_xxxxx ...)

- Mike

By: mike240se (mike240se) 2006-03-06 00:18:10.000-0600

Should I be able to patch this to the current trunk?  It gives a few errors while patching.  Should I upload anything?  the .rej file?

By: mjc (mjc) 2006-03-06 06:47:29.000-0600

I've uploaded metermaid-v2.txt, which has my AST_EXTENSION > AST_DEVICE corrections. Currently, it is using AST_DEVICE_NOT_INUSE and AST_DEVICE_RINGING, but these may or may not be the best settings. Feedback, please!

To apply this against the v1.2.4 tarball, run "patch p0 < metermaid-v2.txt" in the asterisk source directory, and then run "make clean; make install".

I have only tried patching 1.2.4. I don't know what'll happen on the trunk. It wouldn't be a huge surprise if things broke...


- Mike

By: Olle Johansson (oej) 2006-03-06 14:29:36.000-0600

The patch is now in the "metermaids-trunk" branch. I've changed to AST_DEVICE, thanks for discovering that. The states I am using works perfect with Eyebeam, but that's a different kind of subscription that the Snom uses.

The Snom subscription seems broken in general in svn trunk. That is a separate issue that needs to be looked at.

Thanks for testing, please continue. This patch is now also being merged in the "test-this-branch" branch for testing in combination with multiparking - so you can define multiple parking lots.

By: mjc (mjc) 2006-03-08 07:39:04.000-0600

Good news! It works now!

As mike240se suggested, the proper flags are AST_DEVICE_NOT_INUSE and AST_DEVICE_INUSE (not AST_DEVICE_RINGING).

oej, can you update the patch again to change AST_DEVICE_RINGING > AST_DEVICE_INUSE?

To make this work, edit the v2 patch or channels/chan_local.c so that it reads:

   if (!res)
       return AST_DEVICE_NOT_INUSE;
   else
       return AST_DEVICE_INUSE;

In your extensions.conf, add something like:

exten => 701,1,ParkedCall(701)
exten => 701,hint,Local/701@parkedcalls

exten => 702,1,ParkedCall(702)
exten => 702,hint,Local/702@parkedcalls

...etc...

Do not use "include => parkedcalls". You need to add the extensions manually, so that they exist when the phone subscribes to them. Don't use the "parkhints" feature in features.conf either; add the hints manually as above. Remember that macros don't work for hints, for some reason or other.

To use with a phone:

1) Set up your programmable phone buttons as "destinations", with sip address 700, 701, 702 ...

2) Answer a call.

3) Park by transferring to extension 700 (using the programmable button). Hangup.

4) The "701" button light will light up (continuously, not flashing).

5) Retrieve the parked call by pressing the 701 button. Et voila. The light stays on until you finish talking. (Not sure if that's a good thing).

I've tested this with Snom 200 and Snom 360 phones.

This needs to be tested with several people parking / retrieving simultaneously. I only have two hands, so it would be helpful if someone else could check that out.

- Mike

By: mjc (mjc) 2006-03-08 07:44:11.000-0600

I've uploaded a "v3" patch which has the correct device states, to simplify things. It should apply nicely to v1.2.4.

oej can update the "metermaids-trunk" and "test-this-branch" branches, hopefully, if you want something more cutting edge.

Please test!

- Mike

By: Olle Johansson (oej) 2006-03-08 12:39:17.000-0600

If you suggest changes, please upload patches for my branch - "metermaids-trunk". Thank you.

The release branch is not where we implement new features.

By: mjc (mjc) 2006-03-09 07:57:43.000-0600

oej,

As requested, I've uploaded the "metermaid-v3_for_metermaids_trunk.txt" diff file for your metermaids-trunk branch for my suggested changes.

I couldn't actually get your branch working with my Snom 200, however - not because of my patch, but something is causing errors about not recognizing the SIP PUBLISH command.

I'm new to svn and asterisk hacking, so let me know if I'm doing anything odd.

- Mike

By: mjc (mjc) 2006-03-09 08:34:06.000-0600

Ignore my last comment about SIP PUBLISH errors.

The patched metermaids-trunk works fine for me.

- Mike

By: Olle Johansson (oej) 2006-03-09 09:54:25.000-0600

Thanks. That PUBLISH error message is just for your information. Asterisk does not support PUBLISH and the SNOM shouldn't really try to send us those. I'll bug Snom about it...

By: GarryH (hookhook) 2006-03-11 23:59:56.000-0600

Hi Mjc,
I use "patch -p0 <metermaid-v3.txt" to patch the asterisk 1.24 sources, and then make clean, make and make install successfully. I add "load => chan_local.so" into /etc/asterisk/modules.conf. When I start asterisk, I get the following error: " [chan_local.so]Mar 11 22:58:13 WARNING[16557]: loader.c:325 __load_resource: /usr/lib/asterisk/modules/chan_local.so: undefined symbol: ast_park_metermaid_add
Mar 11 22:58:13 WARNING[16557]: loader.c:499 load_modules: Loading module chan_local.so failed!".

I have already tried this patch on two different machine. Same error message!!

Please help!

By: GarryH (hookhook) 2006-03-12 00:18:27.000-0600

I just tried metermaids-trunk, but I still got the same error message: " [chan_local.so]Mar 11 23:15:45 WARNING[22997]: loader.c:356 __load_resource: /usr/lib/asterisk/modules/chan_local.so: undefined symbol: ast_park_metermaid_add
Mar 11 23:15:45 WARNING[22997]: loader.c:446 print_and_load: Loading module chan_local.so failed!"

By: GarryH (hookhook) 2006-03-12 00:35:30.000-0600

I finally figure out how to make it work. We need to add "load => res_features.so" before "load => chan_local.so".

That's it!

By: mike240se (mike240se) 2006-03-12 01:32:42.000-0600

mike, thanks a million for working on this, i am glad the changes i suggested worked.  I am about to patch a production 1.2.5 enviroment assuming v3 applies cleanly to 1.2.5 otherwise i will go back to 1.2.4 since there were no changes from .4 to .5 that affect me (i think).  I will be using it on snom 360's.  One thing i noticed was that you said to transfer the call to 700.  When you set up 701,1,ParkedCall(701), will that let you transfer to 701? I assume we would need to make it parkandannounce() basically i dont want to waste a BLF button on my snom to park, i only want one parking spot and would like to use a button for parking the call and picking up the parked call.  I havent played with it yet, but i assume it should be possible.  Also would be nice if you could just press the blf button without pressing transfer to park the call, maybe snom could add a feature to make a blf button a macro type.  thanks

mike240se

By: GarryH (hookhook) 2006-03-12 01:58:29.000-0600

mike240se:

You could set the "Snom Key" to speed dial 700 to park calls.

By: mjc (mjc) 2006-03-12 07:35:55.000-0600

mike240se,

Personally, am using one of the BLF keys as the "To Park" key (i.e. 700), and three other BLF keys to retrieve 701, 702, and 703.

Parking to a specific slot (e.g., 702) doesn't work. The parking application isn't designed that way, and changing that is beyond my skills.

However, as hookhook mentions, the recent Snom firmware allows you to re-program some of the other keys. Maybe it's possible to re-program the "Snom" key as a "Transfer to 700" parking key - I don't know if it is possible to combine the transfer function and the 700 destination into a single button press. Sure would be handy! Care to try it and report back?

I haven't worked with v1.2.5 yet.

- Mike

By: Olle Johansson (oej) 2006-03-12 09:49:40.000-0600

My multiparking branch (included in test-this-branch too) will allow you to set up multiple parking lots to park in. Feel welcome to test that patch too :-)

By: mike240se (mike240se) 2006-03-12 17:32:50.000-0600

oej, is test-this-branch fixed yet? i couldnt compile, also what version of zaptel does it need to compile?

By: Olle Johansson (oej) 2006-03-13 00:38:26.000-0600

It was fixed many days ago, but problems in the subversion server made it not show up. Please run "svn update" and recompile. It needs the same version of zaptel as svn trunk.

In the future, please don't use the bug tracker for discussions not really related to a bug/patch. The -dev mailing list is a good forum for that. Thanks! :-)

By: Olle Johansson (oej) 2006-03-13 14:09:30.000-0600

We need to find a way to signal properly for all subscribe methods and devices. What works for you on SNOM doesn't really for in Eyebeam...

By: mjc (mjc) 2006-03-13 14:34:57.000-0600

oej,

Can you be more explicit? Do you know why inuse/notinuse are inappropriate for Eyebeam?

- Mike

By: mjc (mjc) 2006-03-14 13:47:44.000-0600

mike240se,

Handy trick: You can re-program the Snom "Snom" key (or the hold key, if you want) in the most recent firmware to trigger a DTMF sequence of "ASTERISK-694". This will create a "call parking" button without using the BLF keys. The downside is that you hear the four DTMF tones.

I don't know if there is a more elegant way of doing this.

- Mike

By: GarryH (hookhook) 2006-03-14 22:41:18.000-0600

mike240se,
I set the second last BLF button to parkorbit 700. During the call, simplely press this button. The call will be parked and the blf led associated to that parking slot should light up immediately, and then you can page someone to pickup the call. This should be the best solution for now.

HookHook

By: dimitripietro (dimitripietro) 2006-04-13 00:18:15

This patch is working well with Aastra Phone and * 1.2.5. But what about * 1.2.6 or 1.2.7 do you think I can apply it on thoses two version ?

By: mjc (mjc) 2006-04-13 08:04:16

dimitripietro,

I'm using it on 1.2.6 with no problems. I haven't tried 1.2.7. Just try patching the 1.2.7 source; it should be obvious from the patch command whether the patch was applied without error or not.

- Mike

By: Steven Ringwald (sringwald) 2006-04-13 09:40:02

Just tried patching 1.2.7, and one of the hunks failed. It was hunk ASTERISK-5, around line 2084.

By: Steven Ringwald (sringwald) 2006-04-18 18:50:49

Is the metermaid feature going to be in the next release of Asterisk?

By: Serge Vecher (serge-v) 2006-05-07 16:00:59

sringwald: please test this code in olle's metermaids-trunk branch. If community members report successful tests of this feature -- it will surely make it into 1.4. Please test and report back. Thanks!

By: djrobinson1 (djrobinson1) 2006-05-09 19:02:10

why were all of the metermaid patches deleted?

By: Serge Vecher (serge-v) 2006-05-09 19:36:46

Several reasons:
1. because the latest code is kept in sync with the trunk in a branch
2. patches attached to the bug were outdated.
3. you can make your own patch, if you so wish, with the following command:
  svn diff http://svn.digium.com/svn/asterisk/trunk http://svn.digium.com/svn/asterisk/team/oej/metermaids > my_own_patch.diff

By: mjc (mjc) 2006-05-10 07:02:43

I think your URL is wrong. Do you mean:

svn diff http://svn.digium.com/svn/asterisk/trunk http://svn.digium.com/svn/asterisk/team/oej/metermaids-trunk > my_own_patch.diff

The metermaid feature has been working great for me, in a production environment with Snom phones.

By: djrobinson1 (djrobinson1) 2006-05-10 09:37:13

Figured out the URL, but am having troubles patching 1.2.7.  Saw someone else had the same problems with hunk 9.  Anyone succesfully done 1.2.7?  If so, what did you have to change?  Thanks.

By: Andrew Miffleton (dfwonsite) 2006-05-10 19:50:11

Does ANYBODY have a copy of the patch pre-made for 1.2.4? I've got a running Asterisk @ Home box in a small company I would really like to add this feature to, but am having problems compiling metermaid-trunk on a identical test machine? If you do have the original patch for * 1.2.4 post the url, i would be most appreciative!!

By: dimitripietro (dimitripietro) 2006-05-10 21:18:52

Yes I do, I just uploaded it.

By: Serge Vecher (serge-v) 2006-05-10 21:25:45

Olle, perhaps this one is ready to go... several reports of production use here ...

By: Andrew Miffleton (dfwonsite) 2006-05-11 08:16:07

Dimitri - THANK YOU VERY MUCH! This worked flawlessly! Perhaps we should rename the above file to metermaid-v3-1.2.4.txt?

By: mjc (mjc) 2006-05-11 08:34:18

Just to clarify, metermaid-v3.txt is known to work on 1.2.4 to 1.2.6. It doesn't work on 1.2.7 - not sure why; I haven't looked into it.

By: Olle Johansson (oej) 2006-05-19 02:29:42

This is on hold for an architectural change. I don't think I have time to finish this before 1.4 freeze. We will have to implement res_features as a channel driver instead of using chan_local as a "proxy" for this kind of notifications.

By: GarryH (hookhook) 2006-05-22 15:24:26

Just made a new patch for asterisk-1.2.7.1. Enjoy!

By: dimitripietro (dimitripietro) 2006-05-22 15:56:01

Nice Thanks for the 1.2.7.1 patch, I will test it in my production system.

By: Steven BerkHolz (steveb) 2006-05-25 19:24:57

I have patched my 1.2.7.1 and built it.
I did various tests and nothing seems broken.
I am getting the hints on my park positions.
ref:
  5404                : Local/5404@parkedcal  State:Unavailable     Watchers  0
  5403                : Local/5403@parkedcal  State:Unavailable     Watchers  0
  5402                : Local/5402@parkedcal  State:Unavailable     Watchers  0
  5401                : Local/5401@parkedcal  State:Idle            Watchers  0
No I just have to get my phone to light up.

This is a great patch and I hope it makes it into 1.4.

By: mjc (mjc) 2006-05-26 06:59:43

Yes, thanks for the 1.2.7.1 patch! I have tested it and confirmed that it works.

- Mike

By: Steven Ringwald (sringwald) 2006-05-30 15:32:44

1.2.7.1 patch seems to work for my use.

Was able to verify that it also worked on the 1.4 SVN, but am not ready to upgrade to the bleeding edge yet.

Thanks for the great work!

By: phat sam (phatsam) 2006-06-12 19:23:46

I am desperately trying to apply this patch to any stable version, please forgive me if this sounds completely lame, but shouldnt i be able to download http://ftp.digium.com/pub/asterisk/releases/asterisk-1.2.7.1.tar.gz and apply the above patch cleanly.  because it doesnt, every hunk fails. (just for sanity check i downloaded a bunch of others with same result) p.s. i only tried this after having checkedout various svn trunks and branches.



By: Todd Shore (teran) 2006-06-12 20:27:01

Is anyone getting the problem where a parked caller ends up talking to another inbound caller?  I have seen this on 1.2.5 on one system and it "went away".  I don't know if it is because of something my new users were doing or not.  I am now seeing it on 1.2.7.1 on another system.



By: mjc (mjc) 2006-06-13 06:52:41

Teran - I haven't seen your problem.

Phatsam - yes, the metermaid-1.2.7.1.txt patch should apply cleanly. Are you changing into the correct directory? Try:

wget http://ftp.digium.com/pub/asterisk/releases/asterisk-1.2.7.1.tar.gz

tar -zxvf asterisk-1.2.7.1.tar.gz

cd asterisk-1.2.7.1

curl "http://bugs.digium.com/file_download.php?file_id=10350&type=bug" > metermaid-1.2.7.1.txt

patch -p0 < metermaid-1.2.7.1.txt


That should work.

By: phat sam (phatsam) 2006-06-13 13:13:14

Thats exactly what i did, and have just copied the above commands line for line, and all patches fail.
1 out of 1 hunk FAILED
12 out of 12 hunks FAILED
6 out of 6 hunks FAILED
1 out of 1 hunk FAILED

By: Todd Shore (teran) 2006-06-16 11:59:12

I have a note of caution for those using Snom phones with parking extensions mapped to destination buttons. If you have a call ringing in on your phone and you press the 701 button, for example, the phone will transfer the incoming call to the parked call.  You will be left without either call and with both callers talking to each other.

By: Olle Johansson (oej) 2006-06-21 09:53:31

Updated branch "metermaids-trunk" to work with current svn trunk. Will have to implement two types of signalling though, to get blinking lamps act differently on different phones...

Moved most of the functionality to res_features instead of embedding it into chan_local.

By: Rob (rob314) 2006-06-21 10:47:32

Teran:  I had this same problem with just the basic transfer of calls and training (also sometimes due to a busy environment).  I believe you need to change the "Transfer On Hook" setting on the phone's web interface.  Changing this to "Off" helped me.

By: furiousgeorge (furiousgeorge) 2006-06-22 08:08:23

All my hunks failed with 1.2.7.1 patch and with v3 patch which i tried against 1.2.6.

A buddy had better luck (inexplicably, though he was using patch 2.4.? and i use 2.5.9) and sent me the files.

I set everything up as described here and on the wiki, here are my results:

-Simply hitting the button set as "park orbit" parks the call, not transfer -> park as descrbed, which i think is great.

-A caller can be be trasfered directly to an extension, but the caller is told "Sorry, invalid" and the call is disconnected.  I would have no problem with this, if it worked, as long as there would be some failsafe from parking one caller on top of another.

-CLI> Show Hints shows two entries for all my local/70Xparkedcalls entries, both are accurate in terms of the status.

-The LEDs arent responding for me.

I guess i have the "eyebeam compatible" version of the early code?  Is there a way to make this happen without trunk?

By: Olle Johansson (oej) 2006-06-22 09:53:06

Please DO NOT test any patches towards 1.2. Please test the branch so that I can get feedback. Thanks.

By: furiousgeorge (furiousgeorge) 2006-06-22 16:58:27

sorry, i got the impression from those two files and the commentary that it was still supported here for 1.2.X

By: Olle Johansson (oej) 2006-06-23 03:07:07

All new development is done for svn trunk. The whole idea with a "release" is *not* to add new bugs embedded in new features...

The 1.2 patches was created by another developer as a backport. Development goes on in trunk where I now have changed the whole code to implement in a different way, without touching chan_local. The branch now has (untested) code for watching meetme's as well :-)

By: mjc (mjc) 2006-06-23 06:40:03

FuriousGeorge,

If you want something for a production system, apply the metermaid-1.2.7.1.txt patch against 1.2.9.1 (that's what I'm using, very happily). If you want to test/develop/improve, use oej's branch.

What phone are you using? My Snom 360 LEDs work fine for showing parking slot status (with 1.2.9.1 + metermaid-1.2.7.1.txt). If "show hints" works correctly but your LEDs don't, that suggests a phone configuration or context problem.

- Mike

By: phat sam (phatsam) 2006-06-23 14:55:17

After going through all the rej files, and finding no real reason why all were failing, i discovered that the patch that is downloaded from this ticket is infact in DOS format! Needless to say i'm confused why this has come about.  However for future reference, and anyone else that wants to try this excellent/necessary feature, convert the file to unix format and everything "just works"(tm). Maybe the patch app is defaulted differently on Gentoo, i dont know.

By: philipp2 (philipp2) 2006-06-26 06:30:46

metermaid-1.2.7.1 is not working out for me on two systems:

1. Debian Sarge, plain asterisk 1.2.9.1 seg faults upon launch with patch applied:

 == Parsing '/etc/asterisk/queues.conf': Found
 Segmentation fault (core dumped)
 karl:/usr/src# Ouch ... error while writing audio data: : Broken pipe
 Ouch ... error while writing audio data: : Broken pipe
 Ouch ... error while writing audio data: : Broken pipe
 Ouch ... error while writing audio data: : Broken pipe

2. Gentoo, bristuffed asterisk 1.2.9.1 doesn't light up the LED on the SNOM 360 (firmware 6.2.2) because "show hints" always gives "idle" for 701 no matter if a caller has been parked or not (the only other patch applied is 5515 for MGCP hint functionality, but that shouldn't interfere).

In both cases it doesn't make a difference if the patch is "unix'ed" first (dos2unix), or if res_features is explicitely loaded before chan_local in modules.conf.

Anyway, I am very much looking forward to 1.4, especially as I see that the "post 1.4" tag was removed from this patch, and oej stated that also meetme is covered in SVN, not just parking - thanks oej! Maybe I can set up a SVN test...

By: Olle Johansson (oej) 2006-06-26 08:55:06

This bug report is only about the patches in the branch for svn trunk. Please do not use it to discuss older code or unsupported patches. You are adding irrelevant information.

Do test the branch where we fix problems and try to get working code. Thanks.

By: Olle Johansson (oej) 2006-06-26 11:44:50

Committed to svn trunk, rev 36055. Thank you all!