[OpenSIPS-Users] B2BUA help

[opensipslist at encambio.com]

Hello Anca,

An ven., févr 12, 2010, Anca Vamanu schrieb:
>opensipslist at encambio.com wrote:
>> An jeu., févr 11, 2010, Anca Vamanu schrieb:
>>> I have just committed the fix for this. Please update and test.
>>>
>> At runtime, my UAC sends INVITE CSEQ 1 to OpenSIPS. [...]
>> Unfortunately, the INVITE arriving at the media server has a
>> CSEQ of 2 so I assume that there is some defect with your
>> changes in SVN 6596.
>>
>It is ok to have cseq 2 on the other side if the received Invite
>has cseq 1. The implementation uses cseq +1 on the other side :).
>It should not be an issue.
>
You're right.

>Only if for the authorized Invite the cseq is not 3... You
>observed this?
>
My observation was wrong, and now it is clear that the B2B logic
is reading INVITE CSEQ 1 and rewriting to INVITE CSEQ 2. When it
retransmits the INVITE a second time with the 'Authorization'
header it does indeed increment the new INVITE CSEQ to 3 which
is correct. Thanks.

But it's still not working...

Problem

The UAC receives the 401 response from the B2B logic and produces
the 'Authorization' string based on RFC 2617 3.2.1/3.2.2. It uses
the original (not B2B rewritten) RURI to calculate the MD5 string.

The B2B logic then takes the new INVITE with the 'Authorization'
header and rewrites the RURI before forwarding it to the media
server. This rewriting procedure is the same for both the RURI
and 'To' URI. Both are set to the <destination> parameter of the
B2B XML file.

When the client entity (media server) gets the new INVITE message
it rejects it because the RURI has changed thus invalidating the
'Authorization' string. Do you understand?

Solution

My idea to solve this problem is when specifying a client
destination in the B2B XML file, a client entity will be created.
As before, the 'To' tag will be rewritten to match the <destination>
but the RURI should not be changed. When B2B forwards the INVITE
message to the media server it will be accepted because the
'Authorization' header will be correct.

Do you agree, and if so what is the best way to achieve this?
Maybe it's best to add this new logic as an option to the
<destination> tag? That way the default behaviour would be
to still rewrite the RURI as B2B was doing before.

Regards,
Brian