[OpenSIPS-Users] B2B bye method handling

[Ross]

Many thanks to Alex (offlist) for pointing out a spurious record_route 
statement on my side was the real culprit to my issue.  Ahh the joys of 
sip routing.

R.

On 09/02/16 05:00 PM, Ross wrote:
> Grabbing it now, I'll send it directly/off-list.
>
>
> R.
>
> On 09/02/16 04:37 PM, Alex Balashov wrote:
>> Ross,
>>
>> Could you provide a libpcap-formatted capture of this scenario, either
>> on-list or privately?
>>
>> -- Alex
>>
>> On 02/09/2016 04:35 PM, Ross wrote:
>>
>>> (I'm new to opensips, so bare with me if I'm off track).
>>>
>>> I setup a very simple configuration using b2bua for a quick top hiding
>>> setup/proxy, and it works correctly, except for handling BYE messages
>>> coming from the upstream connection. Note, db_mode is set to 0 for both
>>> b2b_logic + entities.
>>>
>>> setup: source client (aka invite initiator) -> os/b2b -> upstream
>>>
>>> Quick Issue description:
>>>
>>> Call sessions is established, and works fine, and when the client
>>> disconnects (initiates the bye message), the call disconnects cleanly
>>> with all parties as expected. (this is good/normal)
>>>
>>> But when the server side disconnects first (sends the initial bye
>>> message), opensips improperly handles the bye message by believing it to
>>> be from the client side. Therefore doesn't properly send the
>>> corresponding responses to the remote parties.
>>>
>>> In more detail:
>>>
>>> Delving into the code, and looking at some packet sniffs/debugs, I've
>>> come to the idea that the b2b code (notably starting dlg.c:706) doesn't
>>> take into account that the new BYE message will have the To/From Fields
>>> reversed when from the server as it's not technically a response.
>>> Because of this, the b2b_parse_key on 708 fails as it's only looking at
>>> the "to" field tag for it's index key.
>>>
>>> Then the request falls through and is then incorrectly parsed as a
>>> client sourced packet, as that lookup uses a different index key
>>> (callid), which is correct for the session.
>>>
>>> I've tested this using metaswitch and asterisk in both the client and
>>> server positions and they both return the same data (to/from), but would
>>> like anyone else's thoughts on this.  Apologies, while I can read code,
>>> I'm not a proper programmer to make a real patch.
>>>
>>> Thanks,
>>>    Ross.
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users