[asterisk-dev] Failing SIP sip_hangup()

Steve Davies davies147 at gmail.com
Wed May 12 11:24:13 CDT 2010


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.

Regards,
Steve



More information about the asterisk-dev mailing list