HangUp Groupcall (SIP and DECT)

Hello, I am using Asterisk (16.2.1 on Debian 10 - 16.2.1~dfsg-1+deb10u1) with a FritzBox7590 (FW 7.12 lastest) and an IP-VideoDoorsystem (Dahua VT2000a FW:4.3; VTH1550CH FW:4.3).
As long as I have only 1 external Monitor (SIP/11032) in my dialplan everything is working fine. However, I would like to add my FritzFon C5 (11) into a grouplan - means the external Monitor and my FritzFon C5 should ring if I push my button (9901) on my IP-Videodoorsystem. So far so good.
BUT, if I cancel the call on my FritzFon C5 (11) or my VTH (SIP/11032), the IP-Videosystem and also the other device is still ringing. Only, if I cancel also the call on the other device, the VTO will also stop.
This means the hangup command does not hangup all device - just only the device where I have canncelled the call.

Please find below my sip.con, extensions.conf and the log during the call:
sip.conf:

[general]
language=de
bindport=5060
bindaddr=0.0.0.0
externrefresh=30
nat=force_rport,comedia
srvlookup=yes
transport=udp
;externip=[SipServerIP]
;localnet=10.40.0.1/255.255.0.0
externip=192.168.25.95
localnet=192.168.25.0/255.255.255.0
directmedia=yes
videosupport=yes
;progressinband=yes
;internal_timing=yes
;silencesuppression=no
; register => [UsernameInFritzBox]:[PasswordInFritzBox]@[IPofFritzBox]/[UsernameInFritzBox]
register => vto2000a35:1122334455@192.168.25.1/vto2000a35

; VTO2000A - .35 - RoomNr. 8001
[8001]
host=dynamic
defaultuser=VTO2000A
type=friend
;secret=[PasswordForVTO]
secret=6677889900
context=sip-out
canreinvite=yes
qualify=yes
disallow=all
allow=ulaw
allow=h264
dtmfmode=info
callerid=VTO2000A-35 <8001>

; VTH - SB - .32
[11032]
host=dynamic
defaultuser=VTO2000A
type=friend
;secret=[PasswordForVTO]
secret=6677889900
context=sip-out
canreinvite=yes
qualify=yes
disallow=all
allow=ulaw
dtmfmode=info
videosupport=yes
;progressinband=yes
;internal_timing=yes
;silencesuppression=no
;directmedia=yes
;directrtpsetup=yes
;prematuremedia=no ;this does the exact opposite of what everyone assumes it does
;progressinband=no
callerid=VTH Spitzboden <11032>

; sorgt dafuer dass die internen FritzFon angerufen werden
[videodoorgateway]
context=sip-in
type=friend
insecure=invite
nat=force_rport,comedia instead
;defaultuser=[UsernameInFritzBox]
;fromuser=[UsernameInFritzBox]
defaultuser=vto2000a35
fromuser=vto2000a35
fromdomain=fritz.box
;secret=[PasswordInFritzBox]
;host=[IPofFritzBox]
secret=1122334455
host=192.168.25.1
dtmfmode=rfc2833
disallow=all
allow=ulaw

extensions.conf:

[general]
static=yes
writeprotect=no

[sip-out]
; NoOp notwendig, da die VTH sonst erst Video nach dem Abheben zeigt !
; necessary, otherwise the VTH will only show the video after accepting the call
exten => 9901,1,NoOp(doorbell ring group)
;exten => 9901,1,Set(CALLERID(num)=9901)
exten => 9901,n,Ringing()
exten => 9901,n,Answer()
; exten => 9901,n,Set(CALLER=${CALLERID(num)})
exten => 9901,n,Dial(SIP/11@videodoorgateway&SIP/11032,30,m)
exten => 9901,n,Hangup()

exten => 8001,1,Dial(SIP/8001)          ; VTO-35
exten => 11031,1,Dial(SIP/11031)        ; VTH-31
exten => 11032,1,Dial(SIP/11032)        ; VTH-32
exten => 11033,1,Dial(SIP/11033)        ; VTH-33

[default]
include => sip-out

LOG

asterisk*CLI> 
  == Using SIP VIDEO CoS mark 6
  == Using SIP RTP CoS mark 5
       > 0x563510319230 -- Strict RTP learning after remote address set to: 192.168.25.35:20000
       > 0x563510298bb0 -- Strict RTP learning after remote address set to: 192.168.25.35:20001
    -- Executing [9901@sip-out:1] NoOp("SIP/8001-000000c0", "doorbell ring group") in new stack
    -- Executing [9901@sip-out:2] Ringing("SIP/8001-000000c0", "") in new stack
    -- Executing [9901@sip-out:3] Answer("SIP/8001-000000c0", "") in new stack
       > 0x563510319230 -- Strict RTP switching to RTP target address 192.168.25.35:20000 as source
    -- Executing [9901@sip-out:4] Dial("SIP/8001-000000c0", "SIP/11@videodoorgateway&SIP/11032,30,m") in new stack
  == Using SIP RTP CoS mark 5
  == Using SIP VIDEO CoS mark 6
  == Using SIP RTP CoS mark 5
    -- Called SIP/11@videodoorgateway
    -- Called SIP/11032
    -- Started music on hold, class 'default', on channel 'SIP/8001-000000c0'
    -- SIP/11032-000000c2 connected line has changed. Saving it until answer for SIP/8001-000000c0
       > 0x7ff5c8008300 -- Strict RTP learning after remote address set to: 192.168.25.1:7082
    -- SIP/videodoorgateway-000000c1 is making progress passing it to SIP/8001-000000c0
       > 0x7ff5c8008300 -- Strict RTP switching to RTP target address 192.168.25.1:7082 as source
       > 0x563510298bb0 -- Strict RTP switching to RTP target address 192.168.25.35:20001 as source
       > 0x7ff5c800b630 -- Strict RTP learning after remote address set to: 192.168.25.32:20000
       > 0x7ff5c800ed80 -- Strict RTP learning after remote address set to: 192.168.25.32:20001
    -- SIP/11032-000000c2 is ringing
    -- SIP/11032-000000c2 is making progress passing it to SIP/8001-000000c0
       > 0x7ff5c800ed80 -- Strict RTP switching to RTP target address 192.168.25.32:20001 as source
    -- Got SIP response 486 "Busy Here" back from 192.168.25.1:5060
    -- SIP/videodoorgateway-000000c1 is busy
    -- Got SIP response 486 "Busy Here" back from 192.168.25.32:5060
    -- SIP/11032-000000c2 is busy
  == Everyone is busy/congested at this time (2:2/0/0)
    -- Stopped music on hold on SIP/8001-000000c0
    -- Executing [9901@sip-out:5] Hangup("SIP/8001-000000c0", "") in new stack
  == Spawn extension (sip-out, 9901, 5) exited non-zero on 'SIP/8001-000000c0'
asterisk*CLI> 

Hopefully someone knows how to cancel a groupcall which includes DECT and SIP devices.

Your console trace does not match your description. Rejecting a call does not lead to a 486 response (at least with pjsip). Other than that a dial group is not identical to coupled devices. When a phone cancels, the other ones are still ringing and that is the normal behavior.

Sorry, but it does. This is exactly the log of the following scenario:

  • I am pushing the bell (SIP/8001 - Button 9901)
  • my DECT phone (SIP11@videogateway) and my external monitor (SIP/11032) are ringing
  • pressing the red button on my DECT, the ext. Monitor and my IP-Videodoorsytem are still ringing and I am getting:
    -- Got SIP response 486 "Busy Here" back from 192.168.25.1:5060
    -- SIP/videodoorgateway-000000c4 is busy
       > 0x563510298bb0 -- Strict RTP learning complete - Locking on source address 192.168.25.35:20001
       > 0x563510319230 -- Strict RTP learning complete - Locking on source address 192.168.25.35:20000
  • after pressing the red button on my external monitor I do get the following
    -- Got SIP response 486 "Busy Here" back from 192.168.25.32:5060
    -- SIP/11032-000000c5 is busy
  == Everyone is busy/congested at this time (2:2/0/0)
    -- Stopped music on hold on SIP/8001-000000c3
    -- Executing [9901@sip-out:5] Hangup("SIP/8001-000000c3", "") in new stack
  == Spawn extension (sip-out, 9901, 5) exited non-zero on 'SIP/8001-000000c3'

Pease find below again a log of the complete scenario:

asterisk*CLI> 
  == Using SIP VIDEO CoS mark 6
  == Using SIP RTP CoS mark 5
       > 0x563510319230 -- Strict RTP learning after remote address set to: 192.168.25.35:20000
       > 0x563510298bb0 -- Strict RTP learning after remote address set to: 192.168.25.35:20001
    -- Executing [9901@sip-out:1] NoOp("SIP/8001-000000c3", "doorbell ring group") in new stack
    -- Executing [9901@sip-out:2] Ringing("SIP/8001-000000c3", "") in new stack
    -- Executing [9901@sip-out:3] Answer("SIP/8001-000000c3", "") in new stack
       > 0x563510319230 -- Strict RTP switching to RTP target address 192.168.25.35:20000 as source
    -- Executing [9901@sip-out:4] Dial("SIP/8001-000000c3", "SIP/11@videodoorgateway&SIP/11032,30,m") in new stack
  == Using SIP RTP CoS mark 5
  == Using SIP VIDEO CoS mark 6
  == Using SIP RTP CoS mark 5
    -- Called SIP/11@videodoorgateway
    -- Called SIP/11032
    -- Started music on hold, class 'default', on channel 'SIP/8001-000000c3'
    -- SIP/11032-000000c5 connected line has changed. Saving it until answer for SIP/8001-000000c3
       > 0x7ff5d400cba0 -- Strict RTP learning after remote address set to: 192.168.25.1:7082
    -- SIP/videodoorgateway-000000c4 is making progress passing it to SIP/8001-000000c3
       > 0x7ff5d400cba0 -- Strict RTP switching to RTP target address 192.168.25.1:7082 as source
       > 0x7ff5d401f6a0 -- Strict RTP learning after remote address set to: 192.168.25.32:20000
       > 0x7ff5d4023880 -- Strict RTP learning after remote address set to: 192.168.25.32:20001
    -- SIP/11032-000000c5 is ringing
    -- SIP/11032-000000c5 is making progress passing it to SIP/8001-000000c3
       > 0x563510298bb0 -- Strict RTP switching to RTP target address 192.168.25.35:20001 as source
       > 0x7ff5d4023880 -- Strict RTP switching to RTP target address 192.168.25.32:20001 as source
    -- Got SIP response 486 "Busy Here" back from 192.168.25.1:5060
    -- SIP/videodoorgateway-000000c4 is busy
       > 0x563510298bb0 -- Strict RTP learning complete - Locking on source address 192.168.25.35:20001
       > 0x563510319230 -- Strict RTP learning complete - Locking on source address 192.168.25.35:20000
    -- Got SIP response 486 "Busy Here" back from 192.168.25.32:5060
    -- SIP/11032-000000c5 is busy
  == Everyone is busy/congested at this time (2:2/0/0)
    -- Stopped music on hold on SIP/8001-000000c3
    -- Executing [9901@sip-out:5] Hangup("SIP/8001-000000c3", "") in new stack
  == Spawn extension (sip-out, 9901, 5) exited non-zero on 'SIP/8001-000000c3'
asterisk*CLI> 

Is there a way to have a groupcall and after pressing the red button on one of the devices, all other devices will stop ringing ?
When pressing the green button on my DECT everything is fine. The ext. monitor and my IP-videodoor stops ringing and I can make a call. After pressing the red button also the IP-videostation is silent.

Again, I only need a solution that after pressing the red (cancel) button on one one device all other devices stops also to ring.

I would implement this with something like below
→ Use hangup handler and Dial using b option to collect information about all the channels being dialed out and store them somewhere (Asterisk internal db, db, parent channel).
->On receiving hangup, do some magic to disconnect other channels.

I am not sure if a hangup handler gets called, if a call gets rejected, i.e. if there has never been an active channel.

b ( context^exten^priority ) - Before initiating an outgoing call, Gosub to the specified location using the newly created channel. The Gosub will be executed for each destination channel.

  • context
  • exten
  • priority ( params )
    • arg1 [^ arg1 …]
    • argN

Option b will create a new channel and you can add hangup handler in it.

Hello,
thanks for the reply, but unfortunately my knowledge of Asterisk is not good enough to handle this.
Is there no other way to do this ?

When pressing the red-button on my phone or monitor, I do get a response Got SIP response 486 “Busy Here” from 192.xxx.xxx.xxx:5060
Is there a way to trigger the SIP response 486 and after that to do a “asterisk -rx hangup request all” ?

[sip-out]
; NoOp notwendig, da die VTH sonst erst Video nach dem Abheben zeigt !
; necessary, otherwise the VTH will only show the video after accepting the call
exten => 9901,1,NoOp(doorbell ring group)
exten => 9901,n,Ringing()
exten => 9901,n,Answer()
exten => 9901,n,Dial(${PHONES}&SIP/11@videodoorgateway,30,m)
exten => 9901,n,System(/usr/sbin/asterisk -rx hangup request all)
exten => 9901,n,Hangup()

You must split one dial per line and check DIALSTATUS after each to decide if you’ll end your attempts or continue.
g option for Dial will help you.

Something like this using Local channel,

exten => 9901,n,Dial(Local/s@phones&Local/s@video,30,m)

[phone]
exten => s,1,Dial(${PHONES},30,gm)
same =>n,NOW CHECK HERE FOR 486 AND IF YES THEN DO HANGUP REQUEST ALL

[video]
exten => s,1,Dial(SIP/11@videodoorgateway,30,m)

Note that this is very basic (not tested too) dialplan to give you some idea.

You’re dialing to multiple devices. Why you wanna hangup all other devices when just one is busy?

If that is a premise for your current project, you must check DumpChan at hangup context when the first device send busy status.

With that you will got the originator channel and will request a hangup for him with Command app with hangup request at dialplan.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.