11 Apr
2008
11 Apr
'08
11:05 p.m.
Hi,
Has anyone replaced the functionality of a kagoor voiceflow session
border controller with openser? and is it possible?
TIA
Robert
12 Apr
12 Apr
5:14 a.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
7:43 p.m.
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(a)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
8:09 p.m.
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(a)pernau.at> wrote:
Robert McNaught schrieb:
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users 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
15 Apr
15 Apr
11:51 a.m.
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(a)pernau.at> wrote:
Robert McNaught schrieb:
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users 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
5:11 p.m.
Klaus Darilion <klaus.mailinglists(a)pernau.at> writes:
Gentrice's kaiser schrieb:
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
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).
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…
8:31 p.m.
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(a)berlios.de> wrote:
Klaus Darilion <klaus.mailinglists(a)pernau.at>
writes:
Gentrice's kaiser schrieb:
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
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).
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
17 Apr
17 Apr
7:22 p.m.
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
16 Apr
16 Apr
6:37 p.m.
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(a)berlios.de> wrote:
Klaus Darilion <klaus.mailinglists(a)pernau.at>
writes:
Gentrice's kaiser schrieb:
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
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).
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
17 Apr
17 Apr
7:31 p.m.
Jens Thiele schrieb:
Well - I guess the "depending on your security requirements" is the key
point.
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.
Klaus Darilion <klaus.mailinglists(a)pernau.at>
writes:
of course you should some message screening on the openser before
forwarding it to the registrar.
Gentrice's kaiser schrieb:
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 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).
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.
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
10:55 p.m.
Klaus Darilion <klaus.mailinglists(a)pernau.at> writes:
Well - I guess the "depending on your security requirements" is the
key point.
ack
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
...)
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)
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)
Jens Thiele schrieb:
Well yes. The hard part here is that one may not have enough information
to do "the right thing" at that point.
Klaus Darilion
<klaus.mailinglists(a)pernau.at> writes:
of course you should some message screening on the openser before
forwarding it to the registrar. Gentrice's kaiser schrieb:
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 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).
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.
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 also did take a look at milkfish some time ago and
the config was
really buggy.
ok (so its not me ;-)
Thanks,
Jens
18 Apr
18 Apr
1:21 p.m.
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.
21 Apr
21 Apr
7:38 p.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
9:04 p.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
11:19 p.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
11:44 p.m.
Klaus Darilion wrote:
Robert Dyck wrote:
I think
$fs = ....
should work too
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:
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users 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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
6061
days inactive
6071
days old
16 comments
6 participants
participants (6)
-
Gentrice's kaiser -
Jens Thiele -
Klaus Darilion -
Ovidiu Sas -
Robert Dyck -
Robert McNaught