[asterisk-dev] Failing SIP sip_hangup()

[Steve Davies]

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.

Regards,
Steve