Limit lines on sip phone extension

Asterisk Asterisk Support
1

Hi,

I am trying asterisk with several eyebeam sip phones in a office and have found because eyebeam softphone has 6 lines you can be on a call and hear that someone else is ringing you.

Is there a way to setup asterisk so that once you are on a call anyone else who calls you gets a busy signal so I can send them to voicemail or someone else.

When you transfer someone would you need 2 lines ?.

Thanks

Nick

2

just so you know, we’ve been working on the same issue ourselves for quite some time.

we too use eyebeam, and because there is no way for asterisk to determine how many of those lines are in use, there is no way to effectively limit calls to that extension. i would think that there would be internal logic that would recoginize that a call has been sent to sip/456 and that it shouldn’t send another, but i guess not…

we’ve tried setgroup/checkgroup (in 1.0.7) and group group_count in 1.2, to no avail. incominglimit/outgoinglimit are dead, and call-limit doesn’t seem to be working either.

i’ve been posting all over the web trying to get some more information on this problem (we specifically are having issues with the queue system sending out 2 or 3 calls to an agent at one time) but so far, nadda.

i’m open to any thoughts or suggestions, and will post should i find anything myself.

thanks.

wes

3

Hi,

Ok so having multiple calls coming into our telesales eyebeam sofphones when they are trying to take complex orders will cause big problems.

What other sip or iax softphones would have the config options to limit lines. I would also need a few softphones with video support.

Nick

4

try this in sip.conf

call-limit=1 ; Limit the number of calls!
incominglimit=1 ; Depricated function

Asterisk will report busy for any further calls

rgds

5

[quote=“middletn”]try this in sip.conf

call-limit=1 ; Limit the number of calls!
incominglimit=1 ; Depricated function

Asterisk will report busy for any further calls

rgds[/quote]

tried both, neither work, in any combination, on either 1.0.7 or 1.2.1.

in fact, i’m in my office right now, working on this problem…

right now, we have a four phones set up for testing on a 1.2.1 box. all have call-limit=1 set in sip.conf. one is signed into queue, the rest call into that queue. the first call comes in, and the ‘agent’ phone picks up. sip show inuse gives us this:

* Peer name               In use          Limit
998                       1               1
999                       1               1

if we do a ‘show queues’, we get this:

Members:
 sip/999 (dynamic) (Busy) has taken 11 calls (last was 26 secs ago)
No Callers

now, when a second call comes into queue, * should see that the agent is busy and can’t receive any more calls, right? because the inuse is showing 1 and the queue sees the agent as busy…so there is NO WAY the call should go to that agent phone!

    -- Executing Queue("SIP/2001-90a2", "AML_CUSTOMER_SERVICE") in new stack
    -- Started music on hold, class 'default', on channel 'SIP/2001-90a2'
[b]Jan 14 10:27:30 ERROR[14778]: chan_sip.c:2238 update_call_counter: Call to peer '999' rejected due to usage limit of 1
[/b]    -- Stopped music on hold on SIP/2001-90a2
    -- Playing 'queue-youarenext' (language 'en')
    -- Told SIP/2001-90a2 in AML_CUSTOMER_SERVICE their queue position (which was 1)
    -- Playing 'queue-thankyou' (language 'en')
    -- Started music on hold, class 'default', on channel 'SIP/2001-90a2'
 [b]   -- Called sip/999
    -- SIP/999-9c1b is ringing
    -- SIP/999-9c1b is ringing
    -- SIP/999-9c1b is ringing
    -- SIP/999-9c1b is ringing
    -- SIP/999-9c1b is ringing
 [/b]   -- Started music on hold, class 'default', on channel 'SIP/998-04b5'
    -- SIP/999-9c1b answered SIP/2001-90a2

nope, asterisk calls anyway. it even says that the call is rejected due to a usage limit of 1, but rings the phone anyways. if we do a ‘sip show inuse’, the inuse counter now shows zero, even though there is an active call on the line.

we have replicated this issue on three types of phones now - two softphones (eyebeam and express talk) and a hardphone (polycom IP500). all the phones behave exactly the same.

EDIT

We just spent an hour watching the CLI with debug mode on, and were able to determine exactly where the problem is occurring. This is just doing SIP calls, without the queue, but this problem is what is causing the multiple queue calls issue as well.

Jan 14 11:32:20 DEBUG[22068]: chan_sip.c:2054 sip_call: Outgoing Call for 999
Jan 14 11:32:20 DEBUG[22068]: chan_sip.c:2195 update_call_counter: Updating call counter for outgoing call
Jan 14 11:32:20 ERROR[22068]: chan_sip.c:2238 update_call_counter: Call to peer '999' rejected due to usage limit of 1
Jan 14 11:32:20 DEBUG[22068]: app_dial.c:1112 dial_exec_full: ast call on peer returned -1
Jan 14 11:32:20 DEBUG[22068]: channel.c:1322 ast_hangup: Hanging up channel 'SIP/999-8033'
Jan 14 11:32:20 DEBUG[22068]: chan_sip.c:2402 sip_hangup: Hangup call SIP/999-8033, SIP callid 0fb6ccb62195755e0548e441209376b2@10.100.6.57)
Jan 14 11:32:20 DEBUG[22068]: chan_sip.c:2410 sip_hangup: update_call_counter(999) - decrement call limit counter
Jan 14 11:32:20 DEBUG[22068]: chan_sip.c:2195 update_call_counter: Updating call counter for outgoing call
Jan 14 11:32:20 DEBUG[22068]: chan_sip.c:2232 update_call_counter: Call to peer '999' removed from call limit 1
  == Everyone is busy/congested at this time (0:0/0/0)
Jan 14 11:32:20 DEBUG[22068]: app_dial.c:1586 dial_exec_full: Exiting with DIALSTATUS=CHANUNAVAIL.
Jan 14 11:32:20 DEBUG[22068]: pbx.c:1667 pbx_extension_helper: Launching 'Goto'
    -- Executing Goto("SIP/2001-d337", "s-CHANUNAVAIL|1") in new stack
    -- Goto (macro-mgruser,s-CHANUNAVAIL,1)
Jan 14 11:32:20 DEBUG[22011]: chan_sip.c:11434 sip_devicestate: Checking device state for peer 999
Jan 14 11:32:20 DEBUG[22011]: devicestate.c:187 do_state_change: Changing state for SIP/999 - state 1 (Not in use)
Jan 14 11:32:20 DEBUG[22070]: app_queue.c:471 changethread: Device 'SIP/999' changed to state '1' (Not in use)

The code snippet above shows the CLI for exten 999. Note that 999 is ALREADY on an active call at this point. Note that the call counter is updated, and the call rejected due to a usage limit of 1. All is good, but when we get to the last three lines, the problem appears. chan_sip.c checks the devicestate, and ends up changing 999 to not in use, but the device is still active and on another call. This means that the inuse counter shows zero, and when we attempt to call in again, the call goes through.

This seems like a bug to me, and i’m starting to reach the limits of my understanding of the system. I can provide further information if needs be.

if the author of this thread reads this, please change the original thread title to include [BUG?] so that one of the devs will take a look - maybe they can chime in on this…

6

The phone you were testing, had it initiated a call first? A call limit of one indicates that one inbound and one outboud call may be made. Therefore if you made a call, you still get to recieve one.

;call-limit=1 ; permit only 1 outgoing call and 1 incoming call at a time from the phone to asterisk (1 for the explicit peer, 1 for the explicit user, remember that a friend equals 1 peer and 1 user in memory) . This will affect your subscriptions as well. There is no combined call counter for a “friend” so there’s currently no way in sip.conf to limit to one inbound or outbound call per phone. Use the group counters in the dial plan for that.

I know that this has been worked on recently (within the last 2 weeks), so you might like to try the 1.21 head

Try setting type=peer or user

rgds

7

[quote=“middletn”]The phone you were testing, had it initiated a call first? A call limit of one indicates that one inbound and one outboud call may be made. Therefore if you made a call, you still get to recieve one.
[/quote]

the call we were testing had an active INBOUND call sent to it first, with a second inbound call sent after that. the first time the second call was sent, it was rejected, but asterisk also reset the inuse variable to 0. the second time we attempt to call, the call is sent through. in other words, with call-limit set to 1, asterisk was sending two calls to that line. to my knowledge, this is incorrect.

yes, this was my understanding as well. call-limit=1 should work for what we need, but doesn’t, due to the devicestate being reset. for our agents on the floor, this results in multiple calls being sent to them at once from the queue, because asterisk thinks they’re not on a call, when in fact they are.

we are already using type=peer - that’s one of the first things we changed. i will see about pulling down a copy of head and looking at the source code.

thanks for the input - there is also a bug report on this, and I have added my thoughts to it.

bugs.digium.com/view.php?id=6111

wes

8

FYI, I found a workaround for this issue and have updated the bug tracker with the code changes required.

We now have a FUNCTIONING call-limit on our multi-line devices - Asterisk is finally working like it should for us!

Thanks,

Wes

9

Everyone

Thanks for the info. I will try altering the code and recompiling it as per info above.

Thanks
Nick

10

Excellent. Well done. Wonder how long that bug’s been there.

11

Hi,
I posted a patch for this problem on bugs.digium.com/view.php?id=6111

It needs to be tested, so if some of you want to do so, please send a feedback there :smile:

Thank you.

12

[quote=“cyrax”]Hi,
I posted a patch for this problem on bugs.digium.com/view.php?id=6111

It needs to be tested, so if some of you want to do so, please send a feedback there :smile:

Thank you.[/quote]

Sorry to be ignorant, but can you tell me how I run the patch file? and are the changes you made to be done on a 1.2.1 final file?

rgds

13

you’re not ignorant - i had to learn how to patch last night!

okay, i’ll try to word this clearly…

download the patch file (i named it call-limit.patch because i’m a very simple minded person) and move it to the root level of your asterisk src (in my case /usr/local/src/asterisk-1.2.1). then cd to that directory, and run patch -p1 < name-of-the-patch-file.patch (in my case it was 'patch -p1 < call_limit.patch). Note that the -p1 is the letter P followed by the number 1, not the letter L.

you should have a prompt of some sort at this point, and all you need to do is type ‘channels/chan_sip.c’ - that will locate the chan_sip.c file in the channels directory and patch it.

i did this on a clean download of 1.2.1 and it worked flawlessly - there is another issue regarding call-limit=1 and type=friend (see my other post on here) but i don’t think that is caused by the patch.

i hope this works, and i hope i was clear - if not, let me know.

W

14

The patch is made from a developing relase but it seems that it should work also with the last 1.2 (people reported so…)

Things said by whoiswes about how to apply the patch are correct…
By the way, if you run with -p0 (instead of p1) the patch command will find the file without asking you.

In the .patch file there is a relative path to the file channels/chan_sip.c
The -p option worsk like this: strips directories from the path included in the .patch file…
So if you run it with -p1 in the main source tree, the patch command will not find the file and ask you where it is…

Usually patch are built from the main source tree, so -p0 is the right option.