[OpenSIPS-Users] B2BUA help

[opensipslist at encambio.com]

Hello Anca,

An ven., févr 12, 2010, opensipslist at encambio.com schrieb:
>An ven., févr 12, 2010, Anca Vamanu schrieb:
>>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?
>>
>[...]
>
>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.
>
I've looked at the code and searched for the place where the 'To'
header and RURI are independently set. It seems that some dialog
creation function of the TM module is being used, but I don't see
how to set the 'To' and RURI independently.

Have you thought about the problem I mentioned and the possible
solutions to it? I'm still stuck without a functioning B2BUA,
because the B2B logic is changing the RURI from the original
message.

Regards,
Brian