opensipstack-devel

[OpenSIPStack] Incoming requests handling in upper registration mode

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

Dear all,

I am trying to use OpenSBC in b2bua upper registration mode with 
PortaSIP softswitch. Registration and outgoing calls for UAs behind 
OpenSBC are OK, requests are forwarded through OpenSBC to PortaSIP. 
Contact header hijacking works like a charm. But when it comes to 
incoming calls or, say, NOTIFY from external application server, there 
is a trouble. Rules that govern distinguishing between local and remote 
domains do backfire: since incoming requests hit PortaSIP first, an IP 
in To header does not match the IP address of OpenSBC's listener 
interface. It contains the IP address of PortaSIP.
So OpenSBC first checks the IP in Request-URI, sees that it matches the 
IP address of OpenSBC's listener interface, then checks the To header, 
sees it does not match AND sends request back to PortaSIP. This leads to 
a routing loop.
Can I instruct OpenSBC to overwrite IP address in To header with an AOR 
it knows for the request target and then send it out? Or I am missing 
something? Thanks in advance.

-- 
Sincerely,
Andrew Pogrebennyk

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

[Joegen E. B. <joe...@gm...>]

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

Andrew Pogrebennyk wrote:
> Dear all,
>
> I am trying to use OpenSBC in b2bua upper registration mode with 
> PortaSIP softswitch. Registration and outgoing calls for UAs behind 
> OpenSBC are OK, requests are forwarded through OpenSBC to PortaSIP. 
> Contact header hijacking works like a charm. But when it comes to 
> incoming calls or, say, NOTIFY from external application server, there 
> is a trouble. Rules that govern distinguishing between local and remote 
> domains do backfire: since incoming requests hit PortaSIP first, an IP 
> in To header does not match the IP address of OpenSBC's listener 
> interface. It contains the IP address of PortaSIP.
> So OpenSBC first checks the IP in Request-URI, sees that it matches the 
> IP address of OpenSBC's listener interface, then checks the To header, 
> sees it does not match AND sends request back to PortaSIP. This leads to 
> a routing loop.
> Can I instruct OpenSBC to overwrite IP address in To header with an AOR 
> it knows for the request target and then send it out? Or I am missing 
> something? Thanks in advance.
>
>   

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

Re: [OpenSIPStack] Incoming requests handling in upper registration

[ehernaez <ope...@op...>]

Andrew,


You state that the  to-uri and r-uri are usually the same.  This is not the case when using Upper Registration - where the UA has OSBC as an outbound proxy (as it was designed).  In this case, the r-uri will contain a domain or IP address that is local to OSBC while the to-uri will contain the domain or IP address of the registrar.  Unfortunately there is no solutionton to your issue currently, because OSBC does perform routing based on the to-uri.  However, work is currently underway to allow for more granular routing rules.