Thread: [OpenSBC] OpenSER and OpenSCB as outbound proxy
Brought to you by:
joegenbaclor
Menu
▾
▴
opensipstack-osbcdevel
|
From: Kevin B. <ke...@ei...> - 2007-11-17 16:30:28
|
What I would like to do is have OpenSCB act as an Outbound proxy NAT traversal solution in front of OpenSER (OpenSER acts as the Registrar and main proxy).
Clients who need NAT traversal can set the "outbound proxy" on their SIP UA.
The documentation for OSBC is pretty poor, I'm putting this down partly to help others and partly to get some answers to problems.
Please give comments/advise. I didn't do much testing other than this, so there could be heaps of other issues.
The setup is as follows
UA--------------- OSCB ------------------------------------ OSER ---------------------------- PSTN
[http://oscb.dn.com] [http://oser.dn.com] [http://pstn.dn.com]
The UA is setup as follows
username:123
domain:oser.dn.com
outbound proxy:oscb.dn.com
There are no changes to OpenSER configuration to make this work, if you want you can register directly and make/recieve calls by omitting the "outbound proxy:oscb.dn.com" section on the UA config.
REGISTRATION
============
(note: the usr/psw are configured on OpenSER)
OpenSBC's configuration
SBC mode: B2BUpperReg
Always Proxy Media: Yes
(that's it, for registration, the rest is as default - don't even have Upper Registration Routes as oser.dn.com does not need translation(I guess))
The UA registers with no problem,
Here's a simplified snip from the register message
REGISTER sip:oser.dn.com SIP/2.0. <-- Request URI
From: "123"
To: .
As you cans see neither "Request URI" nor "To URI" are resolved to SBC's IP hence it's sent to the upper registration routes.
When I check OpenSBC registration status, there are two entries (with same call-id)
uri=123@213.224.224.7(ip of SBC) aor=sip:123@78.16.113.195:5065
ur...@os... aor=sip:123@78.16.113.195:5065
When I check OpenSER there is one contact in location DB
sip:123@213.224.224.7:65086 (why port 65086 ??)
You can see here, as expected, that the client registered with IP 78.16.113.195, this was then stored then masqueraded by OpenSBC and sent to OpenSER where the Contact IP is stored as 213.224.224.7 (The IP of OpenSBC).
Any INVITES to OpenSER looking for 12...@os... will resolve it to sip:123@213.224.224.7:65086 (OpenSBC) and openSBC should then proxy it to the UA.
INVITE, BASIC OUTGOING UA TEST CALL
================================
To be able to accept an INVITE you need to make sure the domain used in the 'From URI' appears in the 'Trusted Domain' section.
SBC config
Trusted Domains oser.dn.com > add
I then made a call to an echo test which is running on an Asterisk box.
OpenSER handles the routing so no special routing needed to be configured on OpenSBC
snip from invite
INVITE sip:77...@os... SIP/2.0.
From: "123"
To: .
Contact: .
Since 'To URI' was not 'local' it's sent off to openser which then proxies to the Asterisk echo test.
Resource Counters (during call)
ICT=1 (what are these ? ) NICT=0 IST=0 NIST=0
CallSession=2 Connection=1 Registration=0 RTPSession=2
EventQueue=0 Cache=5 Garbage=3
INVITE, BASIC UA-UA CALL
=====================
I made a call from UA to UA, both using 'outbound proxy' (ie. through SBC)
No problem call worked 2 way voice
Resource Counters (during call)
ICT=6 NICT=0 IST=0 NIST=0
CallSession=4 Connection=2 Registration=0 RTPSession=4
EventQueue=0 Cache=9 Garbage=6
PSTN INCOMING ** PROBLEM **
=========================
The PSTN sends calls with from URI=pstn.dn.com so this had to be set to allowed
Trusted Domains pstn.dn.com > add
Ok, so this was where I hit the first snag, perhaps someone can help on this one
snip from INVITE
INVITE sip:123@213.224.224.7:65086 SIP/2.0.
From: "0860111345"
To:
Contact: .
To explain what happens before this INVITE arrived
An INVITE is sent from pstn.dn.com to oser.pn.com, as you can see the INVITE is to sip:35...@os..., we use the alias function in OpenSER to allow a UA have multiple numbers (this is equaly true for other text aliases, the 'to uri' could be jo...@os...). OpenSER performs an internal lookup on this sip:35...@os..., translates it to 12...@os... then a lookup is performed to find the contact sip:123@213.224.224.7:65086 and this is sent to the SBC
As you can see the request URI (sip:123@213.224.224.7:65086) is correct, it matches the IP of the SBC.
I would think this would be considered local and do a lookup in the local SBC registar and it would then be proxied to the UA, but alas no.
It seems the SBC will only lookup the "to URI" which can't be found in the SBC and worse is sent back to OpenSER which sends it back to the SBC etc..
** IS THERE A SOLUTION TO THIS ??? ** (no, we will not re-write the 'to uri' in OpenSER)
Other problems
SBC crashed several times
one example
2007/11/17 15:45:42.544 HTTP Service:8945460 Error Accept failed for HTTP: Too many open files
2007/11/17 15:45:42.545 HTTP Service:8945460 Message Assertion fail: Operating System error, file tlibthrd.cxx, line 833, Error=24
get the message on the terminal "got here" alot
Some segmentation faults also
"OpenSBC" v1.1.4
|
|
From: Kevin B. <ke...@ei...> - 2007-11-17 19:43:56
|
test test |
|
From: ehernaez <ope...@op...> - 2007-11-18 05:09:29
|
The short answer to your question is that OSBC uses the to-uri for all routing. So, if you want to use it for NAT traversal, the registrar must put the AOR in the to line. There are changes underway that will allow more granular routing rules in OSBC, but it's not there currently. Also, when performing Upper Registration, OSBC uses the base SIP port plus 60020 as a back-door in order to recognize calls for which itshould have a local registration. This explains whythe AOR seen in SER was 65086. |
|
From: Kevin B. <ke...@ei...> - 2007-11-18 17:59:28
|
well it would seem more correct to use the R-URI for doing the lookup of local registered users in openSBC on INVITE from port 65086 instead of 'To'. I added a special check in OpenSER - of the INVITE is being routed to the SBC then 'To-URI' is overwrittend with the R-uri and this WORKS. On security - it would be nice if openSBC had separate trusted domains (checking From-URI) for incoming INVITES on port 65086. If you are using openSBC in this configuration INVITES on 5060 should all be from local UA's but on port 65086 they could be coming from ANY UA's (using foreign From-URI's). The only way to have incoming calls from foreign From-URI's is to 'Accept All Calls' - this basically leaves you with an open proxy. |
|
From: ehernaez <ope...@op...> - 2007-11-19 18:40:24
|
The next release of OSBC will allow routing rules based on the from-uri. This will allow you to exclude any domains that are not trusted. |
|
From: Joegen E. B. <joe...@gm...> - 2007-11-18 06:24:36
|
Work is currently in the pipeline to support this scenario. Right now,
not resolving the To-URI for routing is not supported. If you can make
SER rewrite the to-uri to be the same as the r-uri, then this problem
will be solved.
Other problems
SBC crashed several times
one example
2007/11/17 15:45:42.544 HTTP Service:8945460 Error Accept failed for HTTP: Too many open files
2007/11/17 15:45:42.545 HTTP Service:8945460 Message Assertion fail: Operating System error, file tlibthrd.cxx, line 833, Error=24
get the message on the terminal "got here" alot
Some segmentation faults also
"OpenSBC" v1.1.4
Make sure your file handle limit per process is high enough. The
default is normally 1024 for linux. This is not high enough specially
if opensbc is dynamically creating threads to proxy rtp. There are
also bug fixes in 1.1.5 for zombie rtp threads which might occur during
hold/unhold. I suggest you upgrade using CVS.
Kevin Brennan wrote:
> What I would like to do is have OpenSCB act as an Outbound proxy NAT traversal solution in front of OpenSER (OpenSER acts as the Registrar and main proxy).
> Clients who need NAT traversal can set the "outbound proxy" on their SIP UA.
>
> The documentation for OSBC is pretty poor, I'm putting this down partly to help others and partly to get some answers to problems.
> Please give comments/advise. I didn't do much testing other than this, so there could be heaps of other issues.
>
> The setup is as follows
>
> UA--------------- OSCB ------------------------------------ OSER ---------------------------- PSTN
> [http://oscb.dn.com] [http://oser.dn.com] [http://pstn.dn.com]
>
> The UA is setup as follows
> username:123
> domain:oser.dn.com
> outbound proxy:oscb.dn.com
>
> There are no changes to OpenSER configuration to make this work, if you want you can register directly and make/recieve calls by omitting the "outbound proxy:oscb.dn.com" section on the UA config.
>
> REGISTRATION
> ============
> (note: the usr/psw are configured on OpenSER)
> OpenSBC's configuration
> SBC mode: B2BUpperReg
> Always Proxy Media: Yes
> (that's it, for registration, the rest is as default - don't even have Upper Registration Routes as oser.dn.com does not need translation(I guess))
>
> The UA registers with no problem,
>
> Here's a simplified snip from the register message
>
> REGISTER sip:oser.dn.com SIP/2.0. <-- Request URI
> From: "123"
> To: .
>
> As you cans see neither "Request URI" nor "To URI" are resolved to SBC's IP hence it's sent to the upper registration routes.
>
> When I check OpenSBC registration status, there are two entries (with same call-id)
> uri=123@213.224.224.7(ip of SBC) aor=sip:123@78.16.113.195:5065
> ur...@os... aor=sip:123@78.16.113.195:5065
>
> When I check OpenSER there is one contact in location DB
> sip:123@213.224.224.7:65086 (why port 65086 ??)
>
> You can see here, as expected, that the client registered with IP 78.16.113.195, this was then stored then masqueraded by OpenSBC and sent to OpenSER where the Contact IP is stored as 213.224.224.7 (The IP of OpenSBC).
>
> Any INVITES to OpenSER looking for 12...@os... will resolve it to sip:123@213.224.224.7:65086 (OpenSBC) and openSBC should then proxy it to the UA.
>
> INVITE, BASIC OUTGOING UA TEST CALL
> ================================
> To be able to accept an INVITE you need to make sure the domain used in the 'From URI' appears in the 'Trusted Domain' section.
> SBC config
> Trusted Domains oser.dn.com > add
>
> I then made a call to an echo test which is running on an Asterisk box.
> OpenSER handles the routing so no special routing needed to be configured on OpenSBC
>
> snip from invite
> INVITE sip:77...@os... SIP/2.0.
> From: "123"
> To: .
> Contact: .
>
> Since 'To URI' was not 'local' it's sent off to openser which then proxies to the Asterisk echo test.
>
> Resource Counters (during call)
> ICT=1 (what are these ? ) NICT=0 IST=0 NIST=0
> CallSession=2 Connection=1 Registration=0 RTPSession=2
> EventQueue=0 Cache=5 Garbage=3
>
> INVITE, BASIC UA-UA CALL
> =====================
> I made a call from UA to UA, both using 'outbound proxy' (ie. through SBC)
>
> No problem call worked 2 way voice
>
> Resource Counters (during call)
> ICT=6 NICT=0 IST=0 NIST=0
> CallSession=4 Connection=2 Registration=0 RTPSession=4
> EventQueue=0 Cache=9 Garbage=6
>
>
>
> PSTN INCOMING ** PROBLEM **
> =========================
> The PSTN sends calls with from URI=pstn.dn.com so this had to be set to allowed
> Trusted Domains pstn.dn.com > add
>
> Ok, so this was where I hit the first snag, perhaps someone can help on this one
>
> snip from INVITE
> INVITE sip:123@213.224.224.7:65086 SIP/2.0.
> From: "0860111345"
> To:
> Contact: .
>
> To explain what happens before this INVITE arrived
> An INVITE is sent from pstn.dn.com to oser.pn.com, as you can see the INVITE is to sip:35...@os..., we use the alias function in OpenSER to allow a UA have multiple numbers (this is equaly true for other text aliases, the 'to uri' could be jo...@os...). OpenSER performs an internal lookup on this sip:35...@os..., translates it to 12...@os... then a lookup is performed to find the contact sip:123@213.224.224.7:65086 and this is sent to the SBC
>
> As you can see the request URI (sip:123@213.224.224.7:65086) is correct, it matches the IP of the SBC.
> I would think this would be considered local and do a lookup in the local SBC registar and it would then be proxied to the UA, but alas no.
> It seems the SBC will only lookup the "to URI" which can't be found in the SBC and worse is sent back to OpenSER which sends it back to the SBC etc..
>
>
>
> ** IS THERE A SOLUTION TO THIS ??? ** (no, we will not re-write the 'to uri' in OpenSER)
>
> Other problems
> SBC crashed several times
>
> one example
> 2007/11/17 15:45:42.544 HTTP Service:8945460 Error Accept failed for HTTP: Too many open files
> 2007/11/17 15:45:42.545 HTTP Service:8945460 Message Assertion fail: Operating System error, file tlibthrd.cxx, line 833, Error=24
> get the message on the terminal "got here" alot
> Some segmentation faults also
>
> "OpenSBC" v1.1.4
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Opensipstack-osbcdevel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-osbcdevel
>
>
>
|
Thanks for helping keep SourceForge clean.
X