[Asterisk-Dev] SIP-to-SIP release problem on B-side when using reinvite

[Markku Korpi]

For the records:
This problem seems to be solved after changes in the CVS (in channel.c?) 
during the last  weekend. The SIP release with reinvites works now 
properly, both with
chan_sip and chan_sip2u.

Thanks,
-Markku

John Todd wrote:

> At 10:44 AM +0200 on 5/5/04, Markku Korpi wrote:
>
>> There seems to be a bug in release behaviour of *, when a SIP-to-SIP 
>> call is
>> released by A (calling party) and canreinvite=yes.
>> Namely when A hangs up first, then called party B does not get BYE 
>> from *
>> even though * terminates the call. The call continues to exist on the
>> B-side, while B just hears silence. If the call release is initiate 
>> by B,
>> then the release procedure works properly. In hope to find someone who
>> is/was fihgting with this problem, too, I am describing the problem 
>> in a bit
>> more detail, below.
>>
>> The behaviour is the same with this weekends chan_sip and Olle's latest
>> chan_sip2. I am continuing with debugging, but perhaps someone 
>> already has a
>> diff or a pointer/hint for fixing of this bug?
>>
>> The problem does not appear when reinvites are not used, of course. 
>> However
>> in my current case the customer wants to keep the payload traffic 
>> caused by
>> the SIP-to-SIP calls from its servers and therefore wants * to make 
>> use of
>> SIP reinvites.
>>
>> The problem is extremely deterministic, but nobody else seems to have
>> complained, since I could not find any bug report or other 
>> discussions on
>> this subject.
>>
>> For completeness and for the records, this is at first how the call with
>> reinvites is succesfully established (derived from * sip debug output):
>> (BTW: In this test A was Siemens Pylix and B was X-lite.)
>>
>> A ---------Invite----> * -------Invite ----> B
>>                        * <----100 trying---- B
>> A <----180 Ringing---- * <----180 Ringing--- B
>> A <------200 OK------- * <------200 OK------ B
>>                        * -------Ack--------> B
>> A <------200 OK------- * <------200 OK------ B
>> A -------Ack---------> *
>> at this point call is actually already established, but due to
>> canreinvite=yes * continues with reinvites to A and B:
>>
>> A <--------Invite----- * -------Invite ----> B
>>                        * <----100 trying---- B
>>                        * <----200 OK ------- B
>>                        * -------Ack--------> B
>>                        * -------Ack--------> B
>> A -------200 ok------> *
>> A <------Ack---------- *
>> A <================= talking ==============> B
>>
>> Now the call is established, BUT now it goes wrong when call is 
>> released by
>> A:
>>
>> A ---------Bye-------> *
>> A <------200 OK------- * -------Invite ----> B
>>                Note 1) * <----100 trying---- B
>>                        * <----200 OK ------- B
>>                        * <----200 OK ------- B Note 2)
>>                        * <--------Bye------- B
>>                        * -----200 OK ------> B
>>                        * <----200 OK ------- B
>>                        * <----200 OK ------- B
>>
>> Note 1: At this point * sends reinvite to B correctly but immediately 
>> exits
>> the hangup. Instead, * should have waited for 200 and sent Ack in the 
>> same
>> way as it does when B hangs up first (see trace of that case below).
>> Note 2: B is expecting to get SIP Ack from *, but of course it never 
>> comes
>> because * finished the call already. B tries to repeat 200 OK and then
>> finally tries BYE, etc.
>>
>> Now, here is how it works when B releases first, and how it should 
>> work in
>> the above case, too:
>>
>>                        * <--------Bye------- B
>> A <------Invite ------ * -----200 OK ------> B
>> A ------(Trying)-----> *
>> A -------200 OK------> *
>> A <------Ack---------- *
>> A <------Bye---------- *
>> A -------200 OK------> *
>> As you can see, * retrieves at first the call from  the endpoint by 
>> means of
>> the (re)invite , and then executes call clearing. After this A hears 
>> busy
>> tone (from its its VoIP box) and will hang up.
>>
>> Before I start making and applying a bug fix for this: Does this sound
>> familiar to anyone? How did you fix the problem?
>>
>> Markku Korpi
>
>
>
> Yes, it does sound familiar.  I also see failed SIP BYE messages 
> during certain conversations where IAX2 is used as a trunk.  I'm sorry 
> I don't have a lot more data or as well-described a scenario as you 
> have put together above, but my time is very limited these days and I 
> have a tough time spending cycles on Asterisk debugging due to work 
> priorities.  Let me just say that you're on target, and I await your 
> discoveries and repairs.
>
> JT
>