Re: [OpenSIPStack] Incoming requests handling in upper registration mode

[Andrew P. <and...@po...>]

Joegen,
Thanks for your prompt response. I understand that robust solution that 
would work well in all operation modes of OpenSBC is complex. But I am 
not closing my doors either and hope to approach with an idea of 
improvement one day.
As to your question, what communicates with OpenSBC on PortaSIP side is 
a slightly modified SER. SER does not facilitate From/To headers 
rewriting easily. The position of SER developers is something like "SIP 
is designed to work without replacing the From and To. From and To have 
nothing to do with routing and applications are more likely to break if 
it is changed" (http://www.iptel.org/FAQ_To_From_change). So I am 
interested in finding a solution on OpenSBC side.
Perhaps you could shed more lights on the next question: does OpenSBC 
really need to check To header in upper registration mode to distinguish 
between relay and local handling? I have done a couple of tests in all 
practical use scenarios and found that To and Request-URI are always the 
same: they are set to whatever domain UA was configured with (or 
whatever is the session target in case of incoming calls from PSTN). 
Thank you.

Joegen E. Baclor wrote:
> Hi Andrew,
> 
> I fully understand your situation.  I think the best solution here is to 
> let PortaSIP rewrite the To URI as well.  Is this not a posibility?   As 
> you can see OpenSBC tried its best here to act closest to the specs how 
> the request would have been routed.  Let's say hypothetically that this 
> maybe configurable.    Assume there is a user registered to OpenSBC as 
> sip:61...@op....  Imagine what will happen if OpenSBC received 
> an INVITE like this:
> 
> INVITE sip:61...@fw... SIP/2.0
> From: "alice" <sip:al...@wo...>;tag=123
> To: "Free World Dial-up Echo Server" <sip:61...@fw...>
> 
> This would clearly be a relay at first glance and OpenSBC should forward 
> this to the real destination.   However, since 613 might be a registered 
> user, in this case sip:61...@op..., the hypothetical behavior 
> would be to back off and send the call originally intended for 
> sip:61...@fw... to the 613 user of opensbcdomain.com.
> 
> At first glance this is doable but would entail more work for OpenSBC 
> when in fact the sender could have just written the To URI correctly. 
> 
> I am not closing my doors for this case.  If you think there is an 
> important real-world reason to let OpenSBC handle this behavior then 
> lets start discussing a possible path to take.
> 
> Joegen

-- 
Sincerely,
Andrew Pogrebennyk