[asterisk-dev] Failing SIP sip_hangup()

[Klaus Darilion]

Am 12.05.2010 18:24, schrieb Steve Davies:
> On 12 May 2010 13:21, Steve Davies<davies147 at gmail.com>  wrote:
>> On 12 May 2010 12:06, Olle E. Johansson<oej at edvina.net>  wrote:
>>>
>>> 12 maj 2010 kl. 12.55 skrev Steve Davies:
>>>
>>>> Hi,
>>>>
>>>> (Hope this is a suitably dev-list topic)
>>>>
>>>> I have a scenario where a SIP Invite/Replaces is generated through the
>>>> press of a directed-pickup button on a phone, but the SIP pickup code
>>>> do_magic_pickup() cannot find the call in question (it is in the wrong
>>>> context), In this case I would expect the Invite/Replaces call to be
>>>> hung-up, and that it what the code "tries" to do, as per line 13 of
>>>> the history:
>>>>
>>>> pabx*CLI>  sip show history 3c2671cbaa85-4c7i5s86qb7v
>>>>   * SIP Call
>>>> 1. Rx              INVITE / 1 INVITE / sip:201 at 10.0.0.1
>>>> 2. AuthChal        Auth challenge sent for  - nc 0
>>>> 3. TxRespRel       SIP/2.0 / 1 INVITE - 401 Unauthorized
>>>> 4. SchedDestroy    6400 ms
>>>> 5. Rx              ACK / 1 ACK / sip:201 at 10.0.0.1
>>>> 6. Rx              INVITE / 2 INVITE / sip:201 at 10.0.0.1
>>>> 7. CancelDestroy
>>>> 8. Invite          New call: 3c2671cbaa85-4c7i5s86qb7v
>>>> 9. AuthOK          Auth challenge succesful for snom360
>>>> 10. NewChan         Channel SIP/snom360-0000000f - from
>>>> 3c2671cbaa85-4c7i5s86qb7v
>>>> 11. Xfer            INVITE/Replace received
>>>> 12. TxResp          SIP/2.0 / 2 INVITE - 100 Trying
>>>> 13. Hangup          Cause Unknown
>>>> 14. SchedDestroy    6400 ms
>>>> 15. CancelDestroy
>>>>
>>>> I would expect to see a "Cancel" being sent between lines 13 and 14 -
>>>> Any ideas why it is missing? This results in the Pickup call not being
>>>> cleaned up correctly.
>>> Cancel is sent by the caller to interrupt. We send error codes in response
>>> to the hangup, which happened in line 13 I hope.
>>>
>>> /O
>>
>> I had assumed that the Error response would appear in the History as a
>> TxResp line? Perhaps not.
>>
>> Is seems to me that the call appears to sip_hangup() to be in an "UP"
>> state - If the call is not in an "UP" state, then the History would
>> record:
>>     13. Cancel          Cause Unknown
>> It then determines whether to use "CANCEL" or "603 Decline" depending
>> whether the call was in/outbound.. This would be our desired
>> behaviour. I _think_ that setting
>>     p->invitestate = INV_PROCEEDING
>> at the same time that we send the 100 Proceeding, as per my earlier
>> email, might cause this to correctly happen.
>>
>> I will do a build of this to test it.
>>
>
> I can confirm that setting
>      p->invitestate = INV_PROCEEDING
> during an INVITE/Replace, after sending 100 Trying, and before calling
> do_magic_pickup() fixes the "lost call" behaviour if the pickup fails
> to find a call.

Please file a bug report and add the patch at https://issues.asterisk.org/

regards
Klaus