[Home]

Summary:ASTERISK-22977: chan_sip+CEL: missing ANSWER and PICKUP event for INVITE/w/replaces pickup
Reporter:Walter Doekes (wdoekes)Labels:
Date Opened:2013-12-12 07:23:44.000-0600Date Closed:2014-05-13 09:41:05
Priority:MajorRegression?No
Status:Closed/CompleteComponents:CEL/General Channels/chan_sip/Transfers
Versions:11.7.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) asterisk_config.txt
( 1) c-calls-b-a-picks-up-diff.png
( 2) c-calls-b-a-picks-up-magic.csv
( 3) c-calls-b-a-picks-up-rfc.csv
( 4) c-calls-b-a-picks-up-rfcpatched.csv
( 5) hack-chan_sip-rfc-notify-if-notifyhold_is_yes.patch
( 6) issueA22977-add_cel_ANSWER_and_PICKUP_to_invite_w_replaces.patch
Description:_Apologies for the verbosity of this bug report. I'm new to CEL, so it took more effort to ensure that I was right._

When doing an INVITE-with-Replaces call pickup in Asterisk, the code that does the pickup is split into a regular pickup {{handle_invite_replaces}} and a magic pickup {{do_magic_pickup}}.

Apparently the first form does not send out all the expected CEL events: one missing CEL_ANSWER and one missing CEL_PICKUP.

h2. Magic pickup

When chan_sip handles the device state subscriptions and sends out the dialoginfo notifications, it uses a magic "pickup-<SUBSCRIBE-CALLID>" callid. Like this:

{noformat}
 NOTIFY sip:account_a@10.101.10.169:5060 SIP/2.0
 Call-ID: 1f194a3e-d4cc1c67@10.101.10.169
...
 <?xml version="1.0"?>
 <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="55" state="full" entity="sip:account_b@10.101.10.156">
 <dialog id="account_b" call-id="pickup-1f194a3e-d4cc1c67@10.101.10.169" local-tag="11d09bbdc6a4868a" remote-tag="as17b40255" direction="recipient">
...
{noformat}

(Note how the call-id in the NOTIFY header is equal to the one in the dialog element.)

This "pickup-"-prefixed call-id is recognised and an alternative code path is used to handle the pickup. That path uses {{app_directed_pickup.so}} to pick up the call. This generates certain CEL events.

h2. Regular pickup

When an outside source handles the device state notifications. No magical call-id is used. A NOTIFY now looks like this:

{noformat}
 NOTIFY sip:account_a@10.101.10.169:5060 SIP/2.0
 Call-ID: 1f194a3e-d4cc1c67@10.101.10.169
...
 <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="56" state="full" entity="sip:account_b@10.101.10.156">
 <dialog id="account_b" call-id="2659507032ee3e59342d1b4e1d306173@10.101.10.156:5060" local-tag="fd81a08106cb652i2" remote-tag="as507b394a" direction="recipient">
...
{noformat}

(Note how in this case the call-id attribute holds the call-id of the actual INVITE to account_b.)

Asterisk still handles the pickup properly, but it now *doesn't* require the loading of {{app_directed_pickup.so}} and it sends out less CEL events than it should.

h2. Differences

{{account_a}} subscribes to {{account_b}},
{{account_c}} calls {{account_b}} and {{account_a}} picks up the call.

This yields these CEL events from the start of the call until the call is bridged between {{account_c}} and {{account_a}}.

Magic pickup:

{noformat}
"CHAN_START"
"APP_START"
"CHAN_START"
"CHAN_START"
"PICKUP"
"ANSWER"
"LINKEDID_END"
"ANSWER"
"BRIDGE_START"
"HANGUP"
"CHAN_END"
{noformat}

Regular pickup:

{noformat}
"CHAN_START"
"APP_START"
"CHAN_START"
"CHAN_START"
"LINKEDID_END"
"HANGUP"
"CHAN_END"
"ANSWER"
"BRIDGE_START"
{noformat}

I'm assuming the order of the CEL events are not terribly important.
Note how ANSWER and PICKUP are missing in the second case.

See:
{{c-calls-b-a-picks-up-magic.csv}}
{{c-calls-b-a-picks-up-rfc.csv}}
{{c-calls-b-a-picks-up-diff.png}} ( JIRA gives it content-type text/plain :( )

h2. Reproducing

To reproduce with only asterisk, I had to hack chan_sip to make it send out the RFC-style NOTIFYs. I patched it to abuse the {{notifyhold}} setting to enable/disable the hack while running.

See:
{{hack-chan_sip-rfc-notify-if-notifyhold_is_yes.patch}}
{{asterisk_config.txt}}
Comments:By: Walter Doekes (wdoekes) 2013-12-12 10:19:04.069-0600

Patch {{issueA22977-add_cel_ANSWER_and_PICKUP_to_invite_w_replaces.patch}} is a stab at fixing the issue.

The two missing CEL events are now added. Apart from the (now empty) {{appname}} and {{appdata}} columns in the new ANSWER and LINKEDID rows (and the event order, which I deem to be unimportant at this time) the new cel log is equal to the -magic version, as far as I can tell.

See:
{{c-calls-b-a-picks-up-rfcpatched.csv}}
By: Rusty Newton (rnewton) 2013-12-12 18:45:42.875-0600

bq. Apologies for the verbosity of this bug report. I'm new to CEL, so it took more effort to ensure that I was right.

I doubt anyone is unhappy about it. Everyone appreciates the clarity, formatting, and all the work involved. Thanks!