Open Source Sip: [OpenSIPStack] Incoming requests ...

Print

Up to Discussions in OpenSIPStack

3 Replies Last post: Nov 18, 2007 12:17 AM by ehernaez

Guest

Jul 25, 2007 10:55 AM

[OpenSIPStack] Incoming requests handling in upper registration mode

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

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
opensipstack-devel mailing list
opensipstack-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensipstack-devel

Guest

1. Jul 25, 2007 11:53 AM

in response to: Guest

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

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:613@opensbcdomain.com. Imagine what will happen if OpenSBC received
an INVITE like this:

INVITE sip:613@fwd.pulver.com SIP/2.0
From: "alice" ;tag=123
To: "Free World Dial-up Echo Server"

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:613@opensbcdomain.com, the hypothetical behavior
would be to back off and send the call originally intended for
sip:613@fwd.pulver.com 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.

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
opensipstack-devel mailing list
opensipstack-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensipstack-devel

Guest

2. Jul 30, 2007 7:52 AM

in response to: Guest

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

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:613@opensbcdomain.com. Imagine what will happen if OpenSBC received
an INVITE like this:

INVITE sip:613@fwd.pulver.com SIP/2.0
From: "alice" ;tag=123
To: "Free World Dial-up Echo Server"

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:613@opensbcdomain.com, the hypothetical behavior
would be to back off and send the call originally intended for
sip:613@fwd.pulver.com 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

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
opensipstack-devel mailing list
opensipstack-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensipstack-devel

ehernaez

40 posts since
Aug 28, 2007

3. Nov 18, 2007 12:17 AM

in response to: Guest

Re: [OpenSIPStack] Incoming requests handling in upper registration

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.

Go to original post