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

[Walter Doekes (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-22977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Walter Doekes updated ASTERISK-22977:
-------------------------------------

    Attachment: hack-chan_sip-rfc-notify-if-notifyhold_is_yes.patch
    
> chan_sip+CEL: missing ANSWER and PICKUP event for INVITE/w/replaces pickup
> --------------------------------------------------------------------------
>
>                 Key: ASTERISK-22977
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22977
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Transfers
>    Affects Versions: 11.7.0
>            Reporter: Walter Doekes
>         Attachments: asterisk_config.txt, c-calls-b-a-picks-up-diff.png, c-calls-b-a-picks-up-magic.csv, c-calls-b-a-picks-up-rfc.csv, hack-chan_sip-rfc-notify-if-notifyhold_is_yes.patch
>
>
> _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}}
> 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