Hi,
Has anyone replaced the functionality of a kagoor voiceflow session border controller with openser? and is it possible?
TIA
Robert
Hi,
Kagoor is SBC, many features in it. Which version you are running?
Openser is a proxy, it hard to make openser to be a SBC.
we have some experience to replace kagoor , if you need our help, maybe we can talk.
kaiser
在 2008/4/12 上午 4:05 時，Robert McNaught 寫到：
Hi,
Has anyone replaced the functionality of a kagoor voiceflow session border controller with openser? and is it possible?
TIA
Robert
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Klaus,
I believe it is just used for NAT traversal - I have no access to manuals. It is used in conjunction with Broadsoft to handle NAT traversal.
Do you have such a thing as an example config of how this may be achieved? I am reading through the core cookbook and have tried some different routing rules and tutorials online, however, am fumbling around in the dark and there is very little online.
I am OpenSER 1.2.3 using mediaproxy.so, mediaproxy (from AG-projects) and nathelper.so. I believe I want the OpenSER server to save the location of endpoints in a DB so am loading usrloc.so. I believe I also need to set it up to proxy each SIP message through to the application server and simply switch out the real public IP (stored in MySQL) of the endpoint when passing messages back.
Can you tell me whether I am on the right lines?
Robert
On Mon, Apr 14, 2008 at 12:30 AM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Robert McNaught schrieb:
Hi,
Has anyone replaced the functionality of a kagoor voiceflow session border controller with openser? and is it possible?
Depends on the feature. If you use it only for NAT traversal you can easily do it with openser.
regards klaus
Hi,
The hard part is upper register . It means user auth information is stored in Broadsoft instead of your mysql DB. I don't think it is a easy way to make openser to be a SBC to replace kagoor.
What model VF you running? VF-1000 or 3000, maybe I can find some 2nd box here... Now we use a B2BUA to be a SBC. If somebody know the way to solve this issue with openser, I am happy to see/study that.
kaiser
在 2008/4/15 上午 12:43 時，Robert McNaught 寫到：
Klaus,
I believe it is just used for NAT traversal - I have no access to manuals. It is used in conjunction with Broadsoft to handle NAT traversal.
Do you have such a thing as an example config of how this may be achieved? I am reading through the core cookbook and have tried some different routing rules and tutorials online, however, am fumbling around in the dark and there is very little online.
I am OpenSER 1.2.3 using mediaproxy.so, mediaproxy (from AG-projects) and nathelper.so. I believe I want the OpenSER server to save the location of endpoints in a DB so am loading usrloc.so. I believe I also need to set it up to proxy each SIP message through to the application server and simply switch out the real public IP (stored in MySQL) of the endpoint when passing messages back.
Can you tell me whether I am on the right lines?
Robert
On Mon, Apr 14, 2008 at 12:30 AM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Robert McNaught schrieb:
Hi,
Has anyone replaced the functionality of a kagoor voiceflow session border controller with openser? and is it possible?
Depends on the feature. If you use it only for NAT traversal you can easily do it with openser.
regards klaus
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Gentrice's kaiser schrieb:
Hi,
The hard part is upper register . It means user auth information is stored in Broadsoft instead of your mysql DB.
If broadsoft supports "Path" then it should be easy by forwarding the REGISTER to broadsoft and adding a Path header. Further, save() (before or after forwarding) for NAT pinging.
If Path is not supported then it is more complicated (but doable). You have to save() the original contact and the public socket of the client. Further you have to rewrite the contact header before forwarding, so that the URI points to openser. Further, you have to put some identifier into the user part which will then be used to lookup the usrloc table. I think this can be done with raw DB queries.
regards klaus
I don't think it is a easy way to make openser to be a SBC to replace kagoor.
What model VF you running? VF-1000 or 3000, maybe I can find some 2nd box here... Now we use a B2BUA to be a SBC. If somebody know the way to solve this issue with openser, I am happy to see/study that.
kaiser
在 2008/4/15 上午 12:43 時，Robert McNaught 寫到：
Klaus,
I believe it is just used for NAT traversal - I have no access to manuals. It is used in conjunction with Broadsoft to handle NAT traversal.
Do you have such a thing as an example config of how this may be achieved? I am reading through the core cookbook and have tried some different routing rules and tutorials online, however, am fumbling around in the dark and there is very little online.
I am OpenSER 1.2.3 using mediaproxy.so, mediaproxy (from AG-projects) and nathelper.so. I believe I want the OpenSER server to save the location of endpoints in a DB so am loading usrloc.so. I believe I also need to set it up to proxy each SIP message through to the application server and simply switch out the real public IP (stored in MySQL) of the endpoint when passing messages back.
Can you tell me whether I am on the right lines?
Robert
On Mon, Apr 14, 2008 at 12:30 AM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Robert McNaught schrieb:
Hi,
Has anyone replaced the functionality of a kagoor voiceflow session border controller with openser? and is it possible?
Depends on the feature. If you use it only for NAT traversal you can easily do it with openser.
regards klaus
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Klaus Darilion klaus.mailinglists@pernau.at writes:
Gentrice's kaiser schrieb:
Hi,
The hard part is upper register . It means user auth information is stored in Broadsoft instead of your mysql DB.
If broadsoft supports "Path" then it should be easy by forwarding the REGISTER to broadsoft and adding a Path header. Further, save() (before or after forwarding) for NAT pinging.
1. Path may disclose information you do not want to forward (internal network address)
2. You probably don't want to forward arbitrary SIP packets into your internal network
If Path is not supported then it is more complicated (but doable).
I would say (but please correct me ;-):
If Path is not supported by your upstream registrar, which is quite likely, then it is much more complicated and at the moment, depending on your security requirements, not doable without modifying openser code.
You have to save() the original contact and the public socket of the client. Further you have to rewrite the contact header before forwarding, so that the URI points to openser. Further, you have to put some identifier into the user part which will then be used to lookup the usrloc table. I think this can be done with raw DB queries.
The problem is that you want to populate your usrloc at least only on successful replies to a register and that IMHO is not possible. Otherwise any client in your network may populate your usrlow without credentials and depending on your setup just grab other users accounts.
But once more: please correct me - post some example config. My point is: I wasted a lot of time with that and I think it is really bad to make people believe this is easily doable. I ended up using asterisk for this.
Greetings Jens
PS: the closest match I did find is milkfish [1] which has IMHO the problem described above. http://www.milkfish.org/ http://packages.milkfish.org/boozy/Milkfish_Sources_for_OpenWrt-SDK/OpenWrt-...
All - thank you for your replies.
Jens - you mentioned that it is possible to use a B2BUA to overcome nat traversal rather than a session border controller - this seems a simpler concept, and certainly easier to configure. I am familiar with asterisk a lot more than openser.
My question is this. With the users authentication credentials stored in Broadsoft, would this mean we would need to double-provision our users - both in Broadworks and in Asterisk to allow successful registration of endpoints.
We use the Kagoor in our current network to handle home users, and use Edgemarcs as CPE for large offices (which is just a B2BUA anyway I believe - Asterisk)
We are using Broadworks 12 and Kagoor Voiceflow 1000 with OS 5.3.1 (August 2004).
Is there a way to tell if Broadworks 12 is using "Path" from a SIP dump in Wireshark?
Also, as far as being able to not user location on a successful register, is it not possible to set a branch flag on the REGISTER and catch it on the way back on a 200 OK, which would stop anyone being able to populate our database with their location? I am not that familiar with Branch flags, but I believe this would be applicable.?
TiA
Robert
On Tue, Apr 15, 2008 at 7:11 AM, Jens Thiele karme@berlios.de wrote:
Klaus Darilion klaus.mailinglists@pernau.at writes:
Gentrice's kaiser schrieb:
Hi,
The hard part is upper register . It means user auth information is stored in Broadsoft instead of your mysql DB.
If broadsoft supports "Path" then it should be easy by forwarding the REGISTER to broadsoft and adding a Path header. Further, save() (before or after forwarding) for NAT pinging.
- Path may disclose information you do not want to forward (internal
network address)
- You probably don't want to forward arbitrary SIP packets into your
internal network
If Path is not supported then it is more complicated (but doable).
I would say (but please correct me ;-):
If Path is not supported by your upstream registrar, which is quite likely, then it is much more complicated and at the moment, depending on your security requirements, not doable without modifying openser code.
You have to save() the original contact and the public socket of the client. Further you have to rewrite the contact header before forwarding, so that the URI points to openser. Further, you have to put some identifier into the user part which will then be used to lookup the usrloc table. I think this can be done with raw DB queries.
The problem is that you want to populate your usrloc at least only on successful replies to a register and that IMHO is not possible. Otherwise any client in your network may populate your usrlow without credentials and depending on your setup just grab other users accounts.
But once more: please correct me - post some example config. My point is: I wasted a lot of time with that and I think it is really bad to make people believe this is easily doable. I ended up using asterisk for this.
Greetings Jens
PS: the closest match I did find is milkfish [1] which has IMHO the problem described above. http://www.milkfish.org/ http://packages.milkfish.org/boozy/Milkfish_Sources_for_OpenWrt-SDK/OpenWrt-...
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Robert McNaught schrieb:
All - thank you for your replies.
Jens - you mentioned that it is possible to use a B2BUA to overcome nat traversal rather than a session border controller - this seems a simpler concept, and certainly easier to configure. I am familiar with asterisk a lot more than openser.
My question is this. With the users authentication credentials stored in Broadsoft, would this mean we would need to double-provision our users - both in Broadworks and in Asterisk to allow successful registration of endpoints.
We use the Kagoor in our current network to handle home users, and use Edgemarcs as CPE for large offices (which is just a B2BUA anyway I believe - Asterisk)
We are using Broadworks 12 and Kagoor Voiceflow 1000 with OS 5.3.1
what is Broadworks? Is it a SIP proxy/PBX or is it a service provider?
regards klaus
OpenSER was not designed to act as an upper registrar. Under certain conditions, it can emulate an upper registrar (with certain restrictions, of course). It all depends on the requirements: some tasks can be accomplished, but others can't.
Regards, Ovidiu Sas
On Tue, Apr 15, 2008 at 10:11 AM, Jens Thiele karme@berlios.de wrote:
Klaus Darilion klaus.mailinglists@pernau.at writes:
Gentrice's kaiser schrieb:
Hi,
The hard part is upper register . It means user auth information is stored in Broadsoft instead of your mysql DB.
If broadsoft supports "Path" then it should be easy by forwarding the REGISTER to broadsoft and adding a Path header. Further, save() (before or after forwarding) for NAT pinging.
- Path may disclose information you do not want to forward (internal
network address)
- You probably don't want to forward arbitrary SIP packets into your
internal network
If Path is not supported then it is more complicated (but doable).
I would say (but please correct me ;-):
If Path is not supported by your upstream registrar, which is quite likely, then it is much more complicated and at the moment, depending on your security requirements, not doable without modifying openser code.
You have to save() the original contact and the public socket of the client. Further you have to rewrite the contact header before forwarding, so that the URI points to openser. Further, you have to put some identifier into the user part which will then be used to lookup the usrloc table. I think this can be done with raw DB queries.
The problem is that you want to populate your usrloc at least only on successful replies to a register and that IMHO is not possible. Otherwise any client in your network may populate your usrlow without credentials and depending on your setup just grab other users accounts.
But once more: please correct me - post some example config. My point is: I wasted a lot of time with that and I think it is really bad to make people believe this is easily doable. I ended up using asterisk for this.
Greetings Jens
PS: the closest match I did find is milkfish [1] which has IMHO the problem described above. http://www.milkfish.org/ http://packages.milkfish.org/boozy/Milkfish_Sources_for_OpenWrt-SDK/OpenWrt-...
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Jens Thiele schrieb:
Klaus Darilion klaus.mailinglists@pernau.at writes:
Gentrice's kaiser schrieb:
Hi,
The hard part is upper register . It means user auth information is stored in Broadsoft instead of your mysql DB.
If broadsoft supports "Path" then it should be easy by forwarding the REGISTER to broadsoft and adding a Path header. Further, save() (before or after forwarding) for NAT pinging.
Path may disclose information you do not want to forward (internal network address)
You probably don't want to forward arbitrary SIP packets into your internal network
of course you should some message screening on the openser before forwarding it to the registrar.
If Path is not supported then it is more complicated (but doable).
I would say (but please correct me ;-):
If Path is not supported by your upstream registrar, which is quite likely, then it is much more complicated and at the moment, depending on your security requirements, not doable without modifying openser code.
Well - I guess the "depending on your security requirements" is the key point.
You have to save() the original contact and the public socket of the client. Further you have to rewrite the contact header before forwarding, so that the URI points to openser. Further, you have to put some identifier into the user part which will then be used to lookup the usrloc table. I think this can be done with raw DB queries.
The problem is that you want to populate your usrloc at least only on successful replies to a register and that IMHO is not possible.
Wouldn't it be possible to save needed parameters during request processing in AVPs and during 200 response processing save the AVPs using raw DB queries. I think in single-domain setups it is doable. Of course it would be nicer to modify save() to work on responses too.
Otherwise any client in your network may populate your usrlow without credentials and depending on your setup just grab other users accounts.
Even if you save() during request processing and have "bad" data in the usrloc table account hijacking shouldn't be possible because if the registration fails on the registrar, the registrar wont forward incoming calls to openser.
But once more: please correct me - post some example config. My point is: I wasted a lot of time with that and I think it is really bad to make people believe this is easily doable.
I didn't said "easily doable". But I remember I made such an outboundproxy based on openser using a rather old openser version just by using tons of regular expressions and massive message rewriting. Thus I think it is doable (but not easily)
I ended up using asterisk for this.
Greetings Jens
PS: the closest match I did find is milkfish [1] which has IMHO the problem described above. http://www.milkfish.org/ http://packages.milkfish.org/boozy/Milkfish_Sources_for_OpenWrt-SDK/OpenWrt-...
I also did take a look at milkfish some time ago and the config was really buggy.
regards klaus
Klaus Darilion klaus.mailinglists@pernau.at writes:
Jens Thiele schrieb:
Klaus Darilion klaus.mailinglists@pernau.at writes:
Gentrice's kaiser schrieb:
Hi, The hard part is upper register . It means user auth information is stored in Broadsoft instead of your mysql DB.
If broadsoft supports "Path" then it should be easy by forwarding the REGISTER to broadsoft and adding a Path header. Further, save() (before or after forwarding) for NAT pinging.
- Path may disclose information you do not want to forward
(internal network address)
- You probably don't want to forward arbitrary SIP packets into
your internal network
of course you should some message screening on the openser before forwarding it to the registrar.
Well yes. The hard part here is that one may not have enough information to do "the right thing" at that point.
If Path is not supported then it is more complicated (but doable).
I would say (but please correct me ;-):
If Path is not supported by your upstream registrar, which is quite likely, then it is much more complicated and at the moment, depending on your security requirements, not doable without modifying openser code.
Well - I guess the "depending on your security requirements" is the key point.
ack
You have to save() the original contact and the public socket of the client. Further you have to rewrite the contact header before forwarding, so that the URI points to openser. Further, you have to put some identifier into the user part which will then be used to lookup the usrloc table. I think this can be done with raw DB queries.
The problem is that you want to populate your usrloc at least only on successful replies to a register and that IMHO is not possible.
Wouldn't it be possible to save needed parameters during request processing in AVPs and during 200 response processing save the AVPs using raw DB queries. I think in single-domain setups it is doable. Of course it would be nicer to modify save() to work on responses too.
Hmm maybe/yes.
Perhaps another solution would be something like a preliminary registration?
1) REGISTER crosses openser, openser does a save but notes: not yet acknowledged by upstream registrar.
2) if a sucessful reply from the upstream registrar is received, it notes: acknowledged.
3) if an INVITE comes in, only acknowledged registrations are used
But probably will get quite complicated, too? (bad guy can easily fill your usrloc with not yet acknowledged entries ...)
Otherwise any client in your network may populate your usrlow without credentials and depending on your setup just grab other users accounts.
Even if you save() during request processing and have "bad" data in the usrloc table account hijacking shouldn't be possible because if the registration fails on the registrar, the registrar wont forward incoming calls to openser.
Consider the following sequence: 1) User A registers sucessfully. openser usrloc and upstream usrloc are in sync. 2) User B fakes user A registration. upstream says no - but openser already saved => usrlocs are out of sync 3) call from outside which should get to A will go to B (and B might forward to A, staying in the middle of course)
But once more: please correct me - post some example config. My point is: I wasted a lot of time with that and I think it is really bad to make people believe this is easily doable.
I didn't said "easily doable". But I remember I made such an outboundproxy based on openser using a rather old openser version just by using tons of regular expressions and massive message rewriting. Thus I think it is doable (but not easily)
Sorry, I didn't want to say that you said it is easy. It is just when I tried it, I somehow got the impression it would be easy and I want to make sure people know that it is not.
I am still not convinced that it is doable if security matters but otherwise I think we agree. (of course I would still prefer if anybody would come up with a simple solution)
I also did take a look at milkfish some time ago and the config was really buggy.
ok (so its not me ;-)
Thanks, Jens
Otherwise any client in your network may populate your usrlow without credentials and depending on your setup just grab other users accounts.
Even if you save() during request processing and have "bad" data in the usrloc table account hijacking shouldn't be possible because if the registration fails on the registrar, the registrar wont forward incoming calls to openser.
Consider the following sequence:
- User A registers sucessfully. openser usrloc and upstream usrloc are in
sync. 2) User B fakes user A registration. upstream says no - but openser already saved => usrlocs are out of sync 3) call from outside which should get to A will go to B (and B might forward to A, staying in the middle of course)
In step 3 it depends.
Usually, if openser forwards the REGISTER it has to manipulate it.
E.g the following scenario (for simplicity no NAT traversal and no multi-domain): user aor: sip:alice@atlanta.com user contact: sip:1.2.3.4
Registrar is a dumb SIP registrar at domain atlanta.com
Openser acts as outboundproxy, listening on domain obp.atlanta.com.
When openser forwards the REGISTER to the registrar it has to replace the contact header with the contact of itself (so that the registrar will forward the requests to openser). Further, openser has to put some id into the userpart to match incoming INVITEs to the proper user, e.g:
alice ----REGISTER-----> openser REGISTER sip:alice@atlanta.com To: sip:alice@atlanta.com Contact: sip:1.2.3.4
openser ----REGISTER-----> registrar REGISTER sip:alice@atlanta.com To: sip:alice@atlanta.com Contact: sip:userid@obp.atlanta.com
usrloc table of openser: AoR | contact ---------------------------+---------------------------- sip:userid@obp.atlanta.com | sip:1.2.3.4
usrloc table of registrar: AoR | contact ---------------------------+---------------------------- sip:alice@atlanta.com | sip:userid@obp.atlanta.com
Now, depending on how the "userid" is generated in the openser, the system is vulnerable in the above step 3 or not. Of course if the attacker find out how "userid" is generated or it makes brute force registration with all possible userid then the system is vulnerable. Anyway, you are correct - the save() should happen in the reply route after successful 200 OK.
I think a good generic solution would be to make a save() function which takes AoR and Contact from a parameter, e.g.: save("string/pv-spec","string/pv-spec") and this save function should work in reply route too. In single-domain setup the "userid" could be just the username of the AoR, e.g: in request route: $avp(s:contact) = $ct; remove_hf("Contact"); append_hf("Contact: sip:$tU@obp.atlanta.com\r\n"); t_on_reply(...)
in reply route if (200 OK) save("sip:$tU@obp.atlanta.com","$avp(s:contact)");
Thus, for a nice solution I guess you are right - source code modification would be necessary (but it shouldn't be that hard to expand save() to take parameters)
regards Klaus
Hi all!
FYI: I just found this old thread: http://www.openser.org/pipermail/devel/2006-March/002188.html
I think this could work too. The openser is stateless and encodes the routing information into Contact URI param: http://openser.org/docs/modules/1.3.x/nathelper.html#AEN376
Further, if save() is used too (not for routing!!!!), then the openser can be used for NAT pinging too.
regards Klaus
Robert McNaught schrieb:
Hi,
Has anyone replaced the functionality of a kagoor voiceflow session border controller with openser? and is it possible?
TIA
Robert
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Question, is $Ri ( the source IP ) writable and if so would this arbitrary information be available to add_rcv_param? On Monday 21 April 2008, Klaus Darilion wrote:
Hi all!
FYI: I just found this old thread: http://www.openser.org/pipermail/devel/2006-March/002188.html
I think this could work too. The openser is stateless and encodes the routing information into Contact URI param: http://openser.org/docs/modules/1.3.x/nathelper.html#AEN376
Further, if save() is used too (not for routing!!!!), then the openser can be used for NAT pinging too.
regards Klaus
Robert McNaught schrieb:
Hi,
Has anyone replaced the functionality of a kagoor voiceflow session border controller with openser? and is it possible?
TIA
Robert
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Robert Dyck wrote:
Question, is $Ri ( the source IP ) writable and if so would this arbitrary information be available to add_rcv_param?
Hi Robert!
No, it is not readable. It would have to be added to Contact URI parameter as well, e.g. "sip:.....;socket=ip.add.re.ss:port"
Looks like there is always some source code editing necessary - for adding the socket parameter.
Forcing the sendsocket during INVITE routing could be done by extending the force_sendsocket to accept PV too (if it does not yet) or as a workaround by using dp_apply_policy() from domainpolicy module and setting the send_socket_avp manually.
regards klaus
On Monday 21 April 2008, Klaus Darilion wrote:
Hi all!
FYI: I just found this old thread: http://www.openser.org/pipermail/devel/2006-March/002188.html
I think this could work too. The openser is stateless and encodes the routing information into Contact URI param: http://openser.org/docs/modules/1.3.x/nathelper.html#AEN376
Further, if save() is used too (not for routing!!!!), then the openser can be used for NAT pinging too.
regards Klaus
Robert McNaught schrieb:
Hi,
Has anyone replaced the functionality of a kagoor voiceflow session border controller with openser? and is it possible?
TIA
Robert
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Klaus Darilion wrote:
Robert Dyck wrote:
Question, is $Ri ( the source IP ) writable and if so would this arbitrary information be available to add_rcv_param?
Hi Robert!
No, it is not readable. It would have to be added to Contact URI parameter as well, e.g. "sip:.....;socket=ip.add.re.ss:port"
Looks like there is always some source code editing necessary - for adding the socket parameter.
Forcing the sendsocket during INVITE routing could be done by extending the force_sendsocket to accept PV too (if it does not yet) or as a workaround by using dp_apply_policy() from domainpolicy module and setting the send_socket_avp manually.
I think $fs = .... should work too
regards klaus
On Monday 21 April 2008, Klaus Darilion wrote:
Hi all!
FYI: I just found this old thread: http://www.openser.org/pipermail/devel/2006-March/002188.html
I think this could work too. The openser is stateless and encodes the routing information into Contact URI param: http://openser.org/docs/modules/1.3.x/nathelper.html#AEN376
Further, if save() is used too (not for routing!!!!), then the openser can be used for NAT pinging too.
regards Klaus
Robert McNaught schrieb:
Hi,
Has anyone replaced the functionality of a kagoor voiceflow session border controller with openser? and is it possible?
TIA
Robert
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Gentrice's kaiser -
Jens Thiele -
Klaus Darilion -
Ovidiu Sas -
Robert Dyck -
Robert McNaught