[Home]

Summary:ASTERISK-16591: Sip Reason header "Call completed elsewhere" is not passed through local channel in queues
Reporter:Francesco Romano (francesco_r)Labels:
Date Opened:2010-08-19 08:16:34Date Closed:2012-01-12 17:28:34.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) queue_local.txt
( 1) queue_sip.txt
Description:If i put in a queue two members with local channels, the sip reason header is not passed to the under layer sip channel, so if some one answer the queue with ringall strategy, the other phones lists the call as missed. In other words the SIP "Call completed elsewhere" is not trasmitted through local channels.

If i set a queue like this:

299 has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 0s talktime), W:0, C:1, A:0, SL:100.0% within 60s
  Members:
     SIP/203 (Not in use) has taken no calls yet
     SIP/202 (Not in use) has taken 1 calls (last was 437 secs ago)
  No Callers

all works as expected. Enabling the sip debug i can see:

Reliably Transmitting (NAT) to 192.168.1.213:5060:
CANCEL sip:203@192.168.1.213:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.111:5060;branch=z9hG4bK70d70222;rport
Max-Forwards: 70
From: "201" <sip:201@192.168.1.111>;tag=as405f3769
To: <sip:203@192.168.1.213:5060;transport=udp>
Call-ID: 53923e6f0bb1583f320936cd7bc17346@192.168.1.111
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 1.6.2.11
Reason: SIP;cause=200;text="Call completed elsewhere"
Content-Length: 0

If i set the same queue like this:

299 has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 60s
  Members:
     Local/203@from-queue/n (Not in use) has taken no calls yet
     Local/202@from-queue/n (Not in use) has taken no calls yet
  No Callers

the sip cancel is without Reason:

Reliably Transmitting (NAT) to 192.168.1.213:5060:
CANCEL sip:203@192.168.1.213:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.111:5060;branch=z9hG4bK5e0e1565;rport
Max-Forwards: 70
From: "201" <sip:201@192.168.1.111>;tag=as2330a1d9
To: <sip:203@192.168.1.213:5060;transport=udp>
Call-ID: 3f9298175c425a3d5b4a517d6360e1c4@192.168.1.111
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 1.6.2.11
Content-Length: 0

I have attached two log of a call coming from queue 299 with two members 202 and 203 exposing the different behaviours.
Comments:By: Leo Brown (netfuse) 2010-12-24 05:05:48.000-0600

I have tested on 1.6.2 SVN, and can confirm this seems to be included - my Queue with Local channels that include SIP endpoints, leads to the correct header being added:

Scheduling destruction of SIP dialog '127720d75e649ba55035c6b76340ad41@netfuse.org' in 6400 ms (Method: INVITE)
Reliably Transmitting (NAT) to 81.103.234.XXX:59725:
CANCEL sip:441273808XXX@81.103.234.XXX:59725 SIP/2.0
Via: SIP/2.0/UDP 85.13.242.9:5060;branch=z9hG4bK75f2cc95;rport
Max-Forwards: 70
From: "Leo Brown" <sip:056XXXXXXXXX@netfuse.org>;tag=as71e10d55
To: <sip:441273808XXX@81.103.234.XXX:59725>
Call-ID: 127720d75e649ba55035c6b76340ad41@netfuse.org
CSeq: 102 CANCEL
User-Agent: NetFuse Core Switch
Reason: SIP;cause=200;text="Call completed elsewhere"
Content-Length: 0

By: Francesco Romano (francesco_r) 2010-12-24 08:48:53.000-0600

I have now upgraded and tested Asterisk 1.6.2.16-rc1 but for me this bug is still present:
Scheduling destruction of SIP dialog '525a75c2199b96707ff3a48204d0d280@192.168.1.2' in 6400 ms (Method: INVITE)
Reliably Transmitting (no NAT) to 192.168.1.201:5060:
CANCEL sip:501@192.168.1.201:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK6059f782;rport
Max-Forwards: 70
From: "Francesco R" <sip:503@192.168.1.2>;tag=as10d0994a
To: <sip:501@192.168.1.201:5060;transport=udp>
Call-ID: 525a75c2199b96707ff3a48204d0d280@192.168.1.2
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 1.6.2.16-rc1
Content-Length: 0

By: Leo Brown (netfuse) 2010-12-24 13:45:55.000-0600

Hi Francesco,

My current testbed is retreived via:

svn up -r272642 http://svn.digium.com/svn/asterisk/branches/1.6.2

Please build that and can you send the dial plan you are using to test.

Are you sure you are using the "C" flag in the Queue application (Mark all calls as "answered elsewhere" when cancelled)?

Cheers
Leo

By: Francesco Romano (francesco_r) 2010-12-28 12:58:13.000-0600

If i put the 'C' flag in the Queue app, the sip Reason header "Call completed elsewhere" is correctly passed to the Sip endpoints.
My problem is without the 'C' flag.
Perhaps i didn't explained well my issue, but this problem must be corrected only when using the 'ringall' strategy.
As i explained above, if i have two members SIP/202 and SIP/203 in the queue 299 with ringall and the call is answered by extension 202, 203 correctly receive the Reason "Call completed elsewhere"; instead if in the same queue i put Local/202@from-queue/n and Local/203@from-queue/n the reason is not passed. The from-queue context is like this:
[from-queue]
exten => 202,1,Dial(SIP/202)
exten => 203,1,Dial(SIP/203)

By: Mark Michelson (mmichelson) 2012-01-12 17:28:34.290-0600

I've run some tests, and I can confirm that there are no bugs here. This is a misconfiguration.

The 'C' option for Queue and the 'c' option for Dial are designed for this scenario. Specifically, when a local channel is calling Dial or Queue, this is where these options should be used.

So in the case that Francesco is using, then the Dial statements in the [from-queue] context need to have the 'c' option specified. I have set up the situation myself and confirmed that with the 'c' option for Dial, the Reason header is passed along correctly.

I must also stress that you should not use the 'C' option in Queue unless it is a local channel that is calling INTO the queue. If you are calling into a queue from a SIP channel or some other technology, then using the 'C' option will likely not be what you want. The reason is that if you use the 'C' option and nobody answers, then the SIP Reason header will be sent to ALL of the queue members that were called. This is almost certainly not what you want to happen. Now, if a local channel is calling into the queue, then it is implied that perhaps there is another local channel that is calling into a second queue. If someone in the second queue answers, then you definitely do want all the members from the first queue to have the SIP Reason header sent to it.