[OpenSIPS-Users] B2BUA help
anca at opensips.org
Mon Feb 22 12:50:27 CET 2010
You are right, the if RURI is changed the auth response calculation will
get a different result at the media server.
As a solution, I will add a scenario parameter that tells B2B logic not
to change the RURI, but keep the original one.
However, I must warn you again that if you use the complete prepaid
scenario and the media server will request authorization when the caller
is connected the second time to it, then it will not work. Because to
connect the caller to the media server the second time, a reinvite is
sent to the caller and am initial Invite to the media server after the
caller's phone replies with 200 OK. There is no way to do authorization
But you can use only the first part, connecting the user to the media
server only once at the beginning.
opensipslist at encambio.com wrote:
> 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...
>> 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?
>> 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
> Users mailing list
> Users at lists.opensips.org
More information about the Users