< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate-users] Authorization by Proxy to Gateway - B2BUA

I think the difference between b2bua and proxy is an extra call-control logic implemented inside b2bua between uac and uas. I don't need that extra call-control logic, I will rely on the logic implemented by Client and Gateway.

For now I see a problem with assigning CSeq to injected requests involved in password challenge-response negotiation between Proxy and Gateway. According to https://tools.ietf.org/html/rfc3261#section- "Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction". That means I will break Client-generated CSeq. I have an idea to provoke the client to issue an extra request to bump it's CSeq so the numbers will sync. For example make the client do an extra registration request. Or to reject the next client's request with some 3xx error so the client will resend the request again. Those are hacks of course.

BTW, according to https://tools.ietf.org/html/rfc3665#section-3.3 injecting Auth by SIP Proxy is prohibited, the Client must issue all the auth data itself. Anyway, if the client is not capable of that, let's make a hack.

Roman Rybalko
From: Scott Godin
Sent: Wednesday, March 28, 2018 12:15AM +0300
To: Roman Rybalko
Cc: Resiprocate-users
Subject: Re: [reSIProcate-users] Authorization by Proxy to Gateway - B2BUA

FYI - there are 2 B2BUA projects base on resip.  Unfortunately I haven't really played with either of them much to know if they are appropriate for you, nor do I know the state of these projects:


On Tue, Mar 27, 2018 at 5:11 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
It is possible to create a B2BUA using resiprocate/dum, but I don't think starting with repro makes much sense, since there is no management of session / dialog state, which you will need.  This will not be a trivial implementation.