[asterisk-bugs] [JIRA] (ASTERISK-22979) chan_sip+CEL: missing ANSWER and PICKUP event for INVITE/w/replaces pickup

[Rusty Newton (JIRA)]

Rusty Newton created ASTERISK-22979:
---------------------------------------

             Summary: chan_sip+CEL: missing ANSWER and PICKUP event for INVITE/w/replaces pickup
                 Key: ASTERISK-22979
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22979
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: CEL/General, Channels/chan_sip/Transfers
    Affects Versions: 11.7.0
            Reporter: Walter Doekes


_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 at 10.101.10.169:5060 SIP/2.0
  Call-ID: 1f194a3e-d4cc1c67 at 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 at 10.101.10.156">
  <dialog id="account_b" call-id="pickup-1f194a3e-d4cc1c67 at 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 at 10.101.10.169:5060 SIP/2.0
  Call-ID: 1f194a3e-d4cc1c67 at 10.101.10.169
...
  <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="56" state="full" entity="sip:account_b at 10.101.10.156">
  <dialog id="account_b" call-id="2659507032ee3e59342d1b4e1d306173 at 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 imortant.
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}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira