[OpenSER-Users] kagoor voiceflow replacement

[Robert McNaught]

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 at berlios.de> wrote:
> Klaus Darilion <klaus.mailinglists at 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-SDK/package/milkfish-sip/files/etc/openser/milkfish_openser.cfg
>
>
>
>  _______________________________________________
>  Users mailing list
>  Users at lists.openser.org
>  http://lists.openser.org/cgi-bin/mailman/listinfo/users
>