[OpenSIPS-Users] B2BUA help

[Anca Vamanu]

Hi Brian,

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 
here.

But you can use only the first part, connecting the user to the media 
server only once at the beginning.

Regards,

-- 
Anca Vamanu
www.voice-system.ro




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...
>>
>> 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
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>