Inconsistent ring group behaviour depending on how invoked

Asterisk Asterisk Support
1

I’ve configured a ring group that dials 4 phones. It can be invoked either by (a) an internal SIP call to extension 300 or (b) an incoming ZAP call. The problem: different behaviour when invoked by (a) or (b).

In the former case (a), Asterisk excludes a busy extension from the phones it dials (reporting this at the console).
Good:

[quote=“At my console, Asterisk”] – Executing [300@standard:1] Goto(“SIP/297-08227600”, “ringroups-custom-2|s|1”) in new stack
– Goto (ringroups-custom-2,s,1)
– Executing [s@ringroups-custom-2:1] NoOp(“SIP/297-08227600”, “RINGGROUP”) in new stack
– Executing [s@ringroups-custom-2:2] Dial(“SIP/297-08227600”, “SIP/201&SIP/200&SIP/202&SIP/251|20”) in new stack
– Called 201
– Called 200
– Called 202
– Called 251
– SIP/202-0824def0 is ringing
– Got SIP response 486 “Busy” back from 192.168.1.74
– SIP/201-08236118 is busy
– SIP/251-08251e58 is ringing
– SIP/200-08249f88 is ringing
[/quote]
In the latter case (b) however, Asterisk rings all 4 extensions regardless of whether one is busy.
Bad:

[quote=“At my console, Asterisk”] – Executing [s@DID_trunk_1:3] Goto(“Zap/3-1”, “ringroups-custom-2|s|1”) in new stack
– Goto (ringroups-custom-2,s,1)
– Executing [s@ringroups-custom-2:1] NoOp(“Zap/3-1”, “RINGGROUP”) in new stack
– Executing [s@ringroups-custom-2:2] Dial(“Zap/3-1”, “SIP/201&SIP/200&SIP/202&SIP/251|20”) in new stack
– Called 201
– Called 200
– Called 202
– Called 251
– SIP/201-0823dd90 is ringing
– SIP/202-08258238 is ringing
– SIP/200-08253af0 is ringing
– SIP/251-0825d060 is ringing
[/quote]
Can anyone explain this inconsistency? I have a requirement to avoid ringing a busy phone. So I need to remove the inconsistency and have case (b) exhibit the case (a) behaviour (detect and exclude busy phones). Asterisk version: 1.4.9 (I’m interested if this issue is addressed/absent in a newer version; however, please provide explanation+workaround based on 1.4.9 if possible as we cannot undertake a version change immediately.)

extensions.conf:

[numberplan-custom-2]
include=default
.
.
.
exten = 300,1,Goto(ringroups-custom-2|s|1)

[ringroups-custom-2]
exten = s,1,NoOp(RINGGROUP)
exten = s,n,Dial(SIP/201&SIP/200&SIP/202&SIP/251,20)
exten = s,n,Voicemail(200&201,us)

extensions.ael: context DID_trunk_1 { s => { NoOp( I/C RING BT HOME: ${STRFTIME(${EPOCH},,%c)}); &fixcid(); goto ringroups-custom-2|s|1; } };

2

Hi

Is the phone busy in both cases ? and what is the phone ?
before going further I would upgrade 1.4.9 is old. and it shouldnt affect anything and there are many bugfixes.
Basicly it seems to be a phone thing as its that that will report its self busy or not. what does a sip trace show ?

As to work arounds you could use queues or Kevin Flemmings devstate patch but that would mean a rewrite and calling the channels as Local channels.

Ian

3

Hi Ian,

Thanks for your reply; I appreciate your good intentions but my question is very specific and I spent a lot of time trying to make that clear when preparing my post. It has now become somewhat diffused. Yes, 201 WAS busy on the same call in both cases–that is the whole point! (Sorry if I didn’t make that clear enough.)

I would like to establish first of all, why the difference? Clearly whatever else is the case, 201 is detected as busy in case (a). Yet not in case (b). Even though the same Dial command is used. Can anyone suggest how this can possibly happen?

4

Hi

Im sorry but without any sip traces and details of what phone is used then its not possible to say whats happening,

For example a handset may allow 2 concurrent calls so it would not show as busy, if it was “busy” on a call but a second call came in whereas if a 3rd call came in it would.

The console output is fine for call flow and basic trouble shooting but for the issue you describe then sip traces are the only way forward . also the whole picture needs to be known hence the requests for handset type.

Im sorry but you just haven’t supplied enough information.

Ian

5

Well, maybe it’s asking too much to just talk in terms of the Dial command (which is of course really just a piece of configuration and may very well have different effects in different cases).

But it would still be very useful if someone happens to know for instance that the Dial command ALWAYS exhibits the inconsistency I’ve identified… or that in the case of at least one person’s Asterisk setup it does NOT always exhibit this.

Anyway, for what it’s worth, the handsets are Grandstream BT-200. Bearing in mind your comments, Ian, I’ll do some testing with some other handsets too (X-Lite and Zoiper softphones, and a Cisco ATA-186 that I use to interface to an old DECT handset).

To check the SIP trace as you suggested, I turned on SIP debug at the Asterisk CLI, and guess what: it CHANGED THE BEHAVIOUR!!! With SIP debug on, the “desired” behaviour ceases, and even an internal SIP call to 300 causes a busy phone to ring (busy not detected). I toggled debug on and off several times to prove it was really having this effect. This changed behaviour is seen both at the busy handset and in the console output which now reports “201 ringing” even though 201 is busy on another call.

So I may need to try an external SIP trace to probe this issue further. I played around with tethereal once in the past but that may not be ideal so I would welcome some guidance here about the best way to do a SIP trace.

6

Ok

The BT200 supports call waiting and in default this is set to be enabled, So the set wouldnt report busy till it has at least 2 calls.

You need to go to the phones web gui and disable callwaiting.

[quote]or that in the case of at least one person’s Asterisk setup it does NOT always exhibit this[/quote] I can confirm that on all systems I support the sets work as expected. IE if call waiting is enabled then it wont report busy and call the phone and if call waiting is disabled it will report busy.

Ian

7

Tried that yesterday but it made no difference… incidentally, if it was the handset, wouldn’t we expect it to behave the same way all the time, not vary per my case (a) and case (b)?

8

Hi

You have to confirm the handset is sending a 486 back after the invite, hence the need for sip traces. a Busy condition in sip is controlled from the UA not the server, The server just handles the call if it gets a 486. see tools.ietf.org/html/rfc3665#section-3.9 for more details.

It sounds like buggy firmware in the BT200 handsets not responding with the 486 as needed.

will produce a pcap file that can be opened in wireshark and then decode it as sip and you will get a graph of the messaging

Ian

9

[quote=“ianplain”]It sounds like buggy firmware in the BT200 handsets not responding with the 486 as needed.

Thanks for that–have now run tcpdump/wireshark, and the SIP trace shows the BT200 sending a 486 in my case (a), but not in my case (b).

So I still don’t know what is causing this discrepancy between the two cases.

Case (a)

No.     Time        Source                Destination           Protocol Info
      2 1.385341    192.168.1.74          192.168.1.51          SIP/SDP  Request: INVITE sip:300@192.168.1.51, with session description
      3 1.390452    192.168.1.51          192.168.1.74          SIP      Status: 407 Proxy Authentication Required
      4 1.416485    192.168.1.74          192.168.1.51          SIP      Request: ACK sip:300@192.168.1.51
      5 1.436470    192.168.1.74          192.168.1.51          SIP/SDP  Request: INVITE sip:300@192.168.1.51, with session description
      6 1.437003    192.168.1.51          192.168.1.74          SIP      Status: 100 Trying
      7 1.438961    192.168.1.51          192.168.1.74          SIP/SDP  Request: INVITE sip:201@192.168.1.74:5060;transport=udp, with session description
      8 1.449072    192.168.1.51          192.168.1.71          SIP/SDP  Request: INVITE sip:200@192.168.1.71:5060, with session description
      9 1.473784    192.168.1.74          192.168.1.51          SIP      Status: 100 Trying
     10 1.481003    192.168.1.74          192.168.1.51          SIP      Status: 486 Busy
     11 1.481335    192.168.1.51          192.168.1.74          SIP      Request: ACK sip:201@192.168.1.74:5060;transport=udp
     12 1.497539    192.168.1.71          192.168.1.51          SIP      Status: 100 Trying
     13 1.498423    192.168.1.51          192.168.1.73          SIP/SDP  Request: INVITE sip:202@192.168.1.73:5060, with session description
     14 1.499594    192.168.1.71          192.168.1.51          SIP      Status: 180 Ringing
     15 1.500575    192.168.1.51          192.168.1.74          SIP      Status: 180 Ringing
     16 1.524357    192.168.1.73          192.168.1.51          SIP      Status: 100 Trying
     17 1.531687    192.168.1.73          192.168.1.51          SIP      Status: 180 Ringing
     18 1.645372    192.168.1.51          192.168.1.72          SIP/SDP  Request: INVITE sip:251@192.168.1.72:5060, with session description
     19 1.674813    192.168.1.72          192.168.1.51          SIP      Status: 100 Trying
     20 1.677597    192.168.1.72          192.168.1.51          SIP      Status: 180 Ringing

Case (b)

No.     Time        Source                Destination           Protocol Info
      1 0.000000    192.168.1.51          192.168.1.74          SIP/SDP  Request: INVITE sip:201@192.168.1.74:5060;transport=udp, with session description
      2 0.000026    192.168.1.51          192.168.1.71          SIP/SDP  Request: INVITE sip:200@192.168.1.71:5060, with session description
      3 0.000031    192.168.1.51          192.168.1.73          SIP/SDP  Request: INVITE sip:202@192.168.1.73:5060, with session description
      4 0.000036    192.168.1.51          192.168.1.72          SIP/SDP  Request: INVITE sip:251@192.168.1.72:5060, with session description
      5 0.029351    192.168.1.74          192.168.1.51          SIP      Status: 100 Trying
      6 0.045624    192.168.1.74          192.168.1.51          SIP      Status: 180 Ringing
      7 0.047370    192.168.1.72          192.168.1.51          SIP      Status: 100 Trying
      8 0.048591    192.168.1.72          192.168.1.51          SIP      Status: 180 Ringing
      9 0.081855    192.168.1.73          192.168.1.51          SIP      Status: 100 Trying
     10 0.082529    192.168.1.73          192.168.1.51          SIP      Status: 180 Ringing
     11 0.103789    192.168.1.71          192.168.1.51          SIP      Status: 100 Trying
     12 0.109319    192.168.1.71          192.168.1.51          SIP      Status: 180 Ringing
10

Could you do a sip show peers . somethings not right I see 2 extensions on the same IP address

Are both calls made the same way and could you explain it . The first call shows the invite from 74 and a 486 being sent from 74 and a 180 ringing being sent to 74

could you explain exactly what was happening ?

Ian

11

[quote=“ianplain”]Could you do a sip show peers . somethings not right I see 2 extensions on the same IP address

Are both calls made the same way and could you explain it . The first call shows the invite from 74 and a 486 being sent from 74 and a 180 ringing being sent to 74

could you explain exactly what was happening ?

Ian[/quote]
201 is the only phone on IP 74. (I just double-checked with SIP show peers.)

The case (a) call was made by 201 dialling 300, which is the ring group for 200/201/202/251. Not surprisingly, 201 was busy, and this was correctly detected, and Asterisk did not ring 201, but only the other three. This is the behaviour I want to see always. (The same happens if 201 is independently busy and 300 is dialled from elsewhere. I just did it this way for simplicity.)

The case (b) call was an incoming call on the ZAP channel configured to invoke that same ring group (200/201/202/251). The incoming call occurred while 201 was busy on a call it had initiated. But this was NOT correctly detected, and Asterisk DID ring 201 along with the other three. This is the behaviour I want to prevent.

12

[quote=“Reg Edit”]The case (a) call was made by 201 dialling 300, which is the ring group for 200/201/202/251. Not surprisingly, 201 was busy, and this was correctly detected, and Asterisk did not ring 201, but only the other three. This is the behaviour I want to see always. (The same happens if 201 is independently busy and 300 is dialled from elsewhere. I just did it this way for simplicity.)

The case (b) call was an incoming call on the ZAP channel configured to invoke that same ring group (200/201/202/251). The incoming call occurred while 201 was busy on a call it had initiated. But this was NOT correctly detected, and Asterisk DID ring 201 along with the other three. This is the behaviour I want to prevent.[/quote]
I have now produced the desired behaviour by turning off call waiting on the BT200. Good call Ian. I tried this without success earlier but perhaps I missed something because it has now worked.

Great–now I have a workaround, so the discrepancy becomes academic… for now… but I wish we could account for it as it may well come into play in other circumstances.

13

Hi

I think the inconsistency is due to a couple of things,

  1. Possibly flaky firmware on the BT200
  2. Test plan that will show up inconsistent results, The test calls had to be made from a trird party phone not one of the ones thatwas going to be rung.

But to be honest with call waiting enabled what you saw was correct behaviour.

Ian