ASTERISK-16534: [patch] A 'Directed pickup' call is later unable to Hold or Transfer

[Home]

Summary: ASTERISK-16534: [patch] A 'Directed pickup' call is later unable to Hold or Transfer

Reporter: Alec Davis (alecdavis) Labels:

Date Opened: 2010-08-09 23:49:48 Date Closed: 2011-06-07 14:04:52

Priority: Minor Regression? No

Status: Closed/Complete Components: Channels/chan_sip/Transfers

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) bug17823.diff.txt
( 1) directedpick-hold.txt
( 2) manual-directed-pickup-then-hold.txt

Description: Specifically: There is code to prevent an INVITE with Replaces: header while on an existing call.

If notifycid=yes is enabled in sip.conf, after a call has been picked up using directed pickup on an BLF button ('magic pickup' not the **extn method), we are unable to place the call on Hold or to Transfer.

The call just gets dropped.
Asterisk sends "400 Bad request" to phone.

Hardware Grandstream GXP2000 and GXP2010 firmware 1.2.3.5

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

referring to http://www.ietf.org/rfc/rfc3891.txt

Message *3: Alice@phone2 -> Bob

INVITE sip:bob@bobster.example.org
To: <sip:bob@example.org>
From: <sip:alice@phone2.example.org>;tag=8983
Call-ID: 09870@phone2.example.org
CSeq: 1 INVITE
Contact: <sip:alice@phone2.example.org>
Require: replaces
Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472

Comments: By: Alec Davis (alecdavis) 2010-08-10 06:04:05

sip debug traces uploaded.

Both sip traces have been a directed pickup of another ringing extension.

directedpick-hold.txt starts just before the HOLD button is pressed. The call had previously been picked up by using a BLF button. The caller should have been put on hold, instead the call was dropped!

manual-directed-pickup-then-hold.txt starts just before the HOLD button is pressed, but this time the call had previously been picked up by the dialplan executing app_directpickup, by dialling **8612. The caller was put on hold and heard MOH :)
By: Alec Davis (alecdavis) 2010-08-10 20:43:29

bug17823.diff.txt

Adopt the approach as stated in RFC 3891
o There are no adverse effects if the header is unsupported.

When on an existing call, treat an INVITE with 'replaces' as unsupported.
Don't issue '400 Bad Request'
By: Leif Madsen (lmadsen) 2010-08-11 12:40:57

Thanks for the patch!
By: Alec Davis (alecdavis) 2010-08-15 16:49:54

Since r282235 in ASTERISK-16356 which corrected the behaviour of notifycid=yes, we now have a bit more control, prior to the fix in ASTERISK-16356 'magic pickup' was always being used, and were unable to turn it off.

Now with the default behaviour (uses the dialplan), HOLD and TRANSFER work.

However, the patch still applies when notifycid=yes in sip.conf.

By: David Vossel (dvossel) 2010-08-26 11:13:28

I don't understand why the grandstream is including the replaces header after the call has been picked up for the INVITE that is to put the call on hold. I have never seen that before.
By: David Vossel (dvossel) 2010-08-30 11:03:24

I looked into this further and I don't know if this is something we should fix. Correct me if I am wrong but here is my understanding of the situation.

1. The Grandstream is subscribing some device state.
2. The Grandstream gets a NOTIFY that the device is ringing which includes the callid
3. Using the Grandstream's BLF button an INVITE with "Replaces" using the callid
in the NOTIFY is sent to Asterisk indicating that Asterisk should replace the ringing channel with this new one.

--- All is good up to here.

4. After the call is picked up, the Grandsteam attempts to put the call on hold using the SIP specific Re-INVITE way of doing that. The problem is occurring with this Re-INVITE, for some reason it is including the same "Replaces" header as the original INVITE that started the dialog. According to RFC 3891 if the "Replaces" header is present we are supposed to try and honor it. The patch you have up for review just disables Asterisk from looking at the "Replaces" header when a channel is already associated with the dialog, which does not seem like an RFC compliant way of handling this. Since we can't handle the "Replaces" header at that point, terminating the dialog seems like the only option.

Does my analysis seem correct? If so this seems like something that will have to be solved on Grandstream's side rather than ours.
By: Alec Davis (alecdavis) 2010-08-30 15:46:54

dvossel: Your analysis steps 1-4 is correct.
My non RFC compliant patch was born before you'd fixed the magic pickup, noted above.

Already opened a support Ticket with Grandstream the same day I opened this.
But not knowing exactly where the problem lay, was the problem at the time.
By: Alec Davis (alecdavis) 2010-08-30 16:45:35

What would be helpful, to understand this, with notifycid=yes in sip.conf is can someone provide a SNOM sip trace of a call that has been picked up using directed pickup (BLF button??), and then transferred (or put on hold).

I don't have access to SNOM's, perhaps should....
By: David Vossel (dvossel) 2010-08-30 17:49:55

The snom trace looks exactly like your grandstream's except without the "Replaces" header in the re-invite used to put the endpoint on hold. The grandstream should behave just like it would with any other call in regards to how it puts a call on hold after doing the pickup with "Replaces". The fact it used the "Replaces" header in the initial transaction during call setup really has no bearing on how it should behave in later transactions involving hold or transfer.

I'm going to close this since it does not appear to be an issue with Asterisk.