[Home]

Summary:ASTERISK-03400: Application to get sip inuse counter from within dialplan
Reporter:mdu113 (mdu113)Labels:
Date Opened:2005-01-31 14:32:07.000-0600Date Closed:2011-06-07 14:04:53
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip_app_sipinuse.patch
Description:This introduces SIPInUse application that checks user's inuse counter and branches execution accordingly.
I need it to implement in-asterisk call-waiting control for the phones that can't do it on itself (like polycom phones. AFAIK it's no possible to disable callwaiting on polycoms)

****** ADDITIONAL INFORMATION ******

I checked existing applications including app_groupcount and found no suitable solution for this. app_groupcount seems to be the closest match, but it's variables based and doesn't work in case of simultaneous calls to multiple extensions.
With this application I do something like this:
exten => _X.,1,SIPInUse(${EXTEN},1)
exten => _X.,2,Dial(${EXTEN})
exten => _X.,102,Busy
If you decide to merge it, I've submitted disclaimer several weeks ago.
Comments:By: Brian West (bkw918) 2005-01-31 15:24:20.000-0600

At some point isn't the use stuff in chan_sip going away?  Since the group stuff works so much better?

bkw
By: Brian West (bkw918) 2005-01-31 15:25:02.000-0600

yes group count can do this btw. (that is if you set a group)

bkw
By: mdu113 (mdu113) 2005-01-31 17:00:45.000-0600

there's a problem with group stuff if one tries to use it with simultaneous calls. I.e. if you have:

exten => phones,1,CheckGroup(1@phone1)
exten => phones,2,CheckGroup(1@phone2)
exten => phones,3,SetGroup(phone1@phone1) ; sets variable GROUP_phone1=phone1
exten => phones,4,SetGroup(phone2@phone2) ; sets variable GROUP_phone2=phone2
exten => phones,5,Dial(SIP/phone1&SIP/phone2)

Then let's assume phone1 answered and phone2 is available for the calls.
The Dial won't clear variable GROUP_phone2, and for the consequent calls
CheckGroup will execute as though both phone1 and phone2 have active calls until the 1st call which set those variables is ended.
I'm not sure if inuse is decided to go away, but I see it's still present in CVS-head and in both channel types I use - sip and h323.
I thought inuse counter corresponds to the actual channel usage and if so, I believe it's more correct to rely on it than playing games with channel variables. Please correct me if I'm wrong.
By: Brian West (bkw918) 2005-01-31 18:39:59.000-0600

Lets fix it within the current framework and stop inventing the wheel.  I feel this can be solved within app_groupcount so lets patch that and make it work...

bkw
By: k3v (k3v) 2005-01-31 20:39:27.000-0600

This seems unnecessary to me, at least as far as the application.  ChanIsAvail() with the 's' flag, will check the channel state, rather than if a new channel can be requested.  For 'outgoinglimit=' replacement, the Group stuff is a good choice.

exten => check,1,ChanIsAvail(${mychan},s);
exten => check,102,Goto(busy,1);
By: Kevin P. Fleming (kpfleming) 2005-01-31 22:35:09.000-0600

There are ways to solve this using existing methods. For example, if you are delivering a call to "phone1" (extension 301) and want to keep track of it:

exten => 301,1,SetVar(OUTBOUND_GROUP=301@incoming)
exten => 301,2,Dial(SIP/phone1)

During the lifetime of the channel that is created to phone1, it will be assigned group "301" in category "incoming".

If you want to send a call to multiple phones and have assigned groups, you can use Local channels:

[local-deliver]
exten => _phoneX,1,SetVar(OUTBOUND_GROUP=${EXTEN}@incoming)
exten => _phoneX,2,Dial(SIP/${EXTEN})

[dial]
exten => 301,1,Dial(Local/phone1@local-deliver&Local/phone2@local-deliver)

(Although this can produce some very "interesting" CDR records).

In other words, there are ways to accomplish all of this. In fact, you can even track all the different types of calls you have (PSTN-out, PSTN-in, DID-in, internal, queue, etc) with different group names and use GetGroupMatchCount and the appropriate regex to get the extension/phone status and decide what to do from there. The nice thing about this method is that it is channel generic; it works for SIP, IAX, Zap, MGCP and any other channel you may have.
By: mdu113 (mdu113) 2005-02-01 11:01:44.000-0600

2bkw918: I can't see the way to fix it within app_groupcount. I guess it would require patching app_dial to unconditionally clear GROUP_x variables. So I agree with k3v that it can well be used as outgoinglimit replacement. It can also be used as incominglimit, but for single calls only.

2k3v: Thanks! I didn't see that 's' option as it exists in cvs-head only. Quick look through the source code shows that it should do exactly what I was looking for. I'm going to test it and if it's ok I'll try to backport it (hopefully just copy ;-)) to 1.0.5.

2kpfleming: I guess you're right and it's probably can be achieved that way, but honestly I don't like it at all. I'd rather use (or write as far as my limited programming abilities allow) simple enough application to check  channel state then going on the journey of unneccesary complications.
By: mdu113 (mdu113) 2005-02-01 15:38:53.000-0600

Ok, it actually took to modify couple of lines to backport app_chanisavail from cvs-head. It seems to be working fine and does exactly what I needed. Anyone interested in the patch? Otherwise I think this bug can be closed.
By: Mark Spencer (markster) 2005-02-01 21:11:27.000-0600

Well, the backport likely wouldn't make it to stable, so probably not, but I'm glad we were able to find a solution to your problem without requiring another channel-specific application, although I thank you for taking the time to contribute!
By: Russell Bryant (russell) 2005-02-06 21:32:39.000-0600

new features won't make it to 1.0, but thanks again for the contribution