(cc-ing semsdev, as that actually belongs there)
o Andreas Granig on 01/11/2011 04:14 PM:
Regarding the new SIP routing design, is there anything missing
feature-wise in SEMS sbc as of today? The next SEMS release 1.4 is
planned for end of January, it would make sense to use SEMS 1.4 for the
next CE release then.
Actually there is one thing that would really be cool :)
With your latest changes, I'm able to dynamically assign an SBC profile
per call. In order to fully take advantage of that, it would be really
great to have these profiles in the database. That way, I could in the
admin panel of the CE configure per domain or peering server the SBC
profile (e.g. create one profile per peer in order to set the user/pass
for authentication, or filter by codecs etc. etc.) without having to
create a separate file per profile.
as you know - and what you will want to use - you can live reload SBC
profiles in SEMS. There, you can specify the profile name and a full
file path/name to read that profile from. For verification that you
got the right one, you can also list the profiles including MD5 of the
contents.
Instead of adding MySQL or other DB support for configuration into
SEMS, I would rather go the unix way and use a small tool, e.g.
perl/python script, that loads a profile from DB, writes that to a
temporary file, and loads that into SEMS.
E.g., if there's a table in DB like
version varchar(32),
profile_name varchar(32),
config_key varchar(32),
config_value varchar(256)
you could easily write a script that does select
config_key,config_value from sbc_profiles where
profile_name='myprofile' and version='1.0.0.1' and then builds
together a file with config_key="config_value"; and loads that into SEMS.
I could also add a RPC/DI method that directly feeds the profile, but
I actually think for administration, and also for restarts of the
server, you would actually want to have it on disk as well.
I have been thinking about a better and more flexible way of passing
configuration to sems some times, but I was always unsure about what
the best solution is. Implementation-wise, this is most probably
simple to change, as always the very simple AmConfigReader is used.
Stefan
Andreas
Stefan
o Andreas Granig on 01/07/2011 07:04 PM:
Guys,
The next release of the CE will bring a redesign of the SIP routing
architecture in order to allow couple of more things, including
authentication towards peers as requested.
Currently, there's one kamailio instance running on the CE, with SEMS
and Asterisk running side-by-side mainly for media services and
applications.
The new design comes with two kamailios (one as load-balancer and one as
proxy/registrar) and SEMS with SBC module in between, like [client A] ->
[kamailio lb] -> [kamailio proxy] -> [sems sbc] -> [kamailio lb] ->
[peering gw / client B].
Since the SEMS SBC is acting as back-to-back user-agent, it can
authenticate calls in behalf of the platform, as well as playing early
media etc. etc.
We're going to release a beta around end of January, leveraging these
new features. The next stable release will be available by end of March.
Andreas
On 01/06/2011 05:02 PM, Chris Michael wrote:
That's fantastic! We'll try implementing over the next few days and
let the group know how we get on.
Many thanks.
On 6 Jan 2011, at 15:59, Stefan Sayer wrote:
Hi,
here follows a short tutorial on how to use newer SEMS to register
to 3rd party SIP provider and authenticate *outgoing calls*.
(Incoming calls are not supported atm, in fact they will probably be
sent back to the 3rd party).
Possibly the sipwise wizards can integrate something like that into
the next ngcp release.
-------------------------------------------------------------------
Using SEMS to register to SIP provider and authenticate calls
through a B2BUA
Here is how current SEMS can be used to register an ngcp-ce to a SIP
provider, and authenticate outgoing calls.
Handling incoming calls is not supported at the moment, this will be
added in the next part of this tutorial.
1. get & unpack SEMS:
Unfortunately, the SEMS version in use in the ngcp repos too old to
contain the SBC module.
therefore we will just download and unpack the SEMS package and
install it into /opt/sems/
like this:
~# cd /opt/
/opt# mkdir sems && cd sems
/opt/sems# wget
ftp://ftp.iptel.org/pub/sems/1.4/1.4.0-dev423329a/packages/debian/lenny64/sems_1.4.0-dev423329a_amd64.deb
/opt/sems# ar x sems_1.4.0-dev423329a_amd64.deb ; tar xzvf data.tar.gz
/opt/sems# rm data.tar.gz debian-binary control.tar.gz
2. edit config files
In these config files, there are explanations for each of the config
settings. Some are commented (with a hash #), some not. I'm assuming
I want to register as user 8111111 at sipgate.de with the password
4asdb11 (just an example).
Adapt these settings:
/opt/sems# joe etc/sems/sems.conf
sip_ip=<your public IP>
sip_port=5090
plugin_path=/opt/sems/usr/lib/sems/plug-in/
load_plugins=reg_agent;registrar_client;uac_auth;session_timer;sbc
application=sbc
plugin_config_path=/opt/sems/etc/sems/etc/
unhandled_reply_loglevel=info
(Ctrl-KX to save and exit)
/opt/sems# joe etc/sems/etc/reg_agent.conf
domain=sipgate.de
user=8111111
display_name=8111111
auth_user=8111111
pwd=4asdb11
/opt/sems# joe etc/sems/etc/sbc.conf
profiles=auth_b2b
active_profile=auth_b2b
/opt/sems# joe etc/sems/etc/auth_b2b.sbcprofile.conf
RURI=sip:[email protected]
From="\"8111111\" <sip:[email protected]>"
To="\"$rU\" <sip:$...@$sipgate.de>"
enable_auth=yes
auth_user=8111111
auth_pwd=4asdb11
3. check out whether registering works:
/opt/sems# usr/sbin/sems -f etc/sems/sems.conf -D 3 -E
now you should see many log lines, and pretty much at the end
something like
"DEBUG: positive reply to REGISTER!", two boxes with "DEBUG: ---
Contact Info ---"
and periodically messages like:
"DEBUG: Got state RegisterActive with expires 590s for registration."
If that's the case, you are registered.
Now you can create a peering server, in a peering group, like:
Name: sipgate through SEMS
IP Address: <your public IP>
Port: 5090
Weight: 1
and place a call. In the log you should now see many lines with SIP
messages, specifically an INVITE coming in, and INVITE being sent
out, a 407 coming back, another INVITE going out etc. If you are
getting 407 back to the caller, the user/password you entered above in
auth_b2b.sbcprofile.conf is probably not correct.
4. start SEMS as a daemon
In the terminal window that you have open above, you can hit Ctrl-C
to stop SEMS.
Now we adapt the init files to start the SEMS from /opt as a daemon:
/opt/sems# joe etc/default/sems
SEMS_CFG_FILE="/opt/sems/etc/sems/sems.conf"
SEMS_PIDFILE="/var/run/sems/sems-sbc.pid"
/opt/sems# joe etc/init.d/sems
if test -f /opt/sems/etc/default/sems ; then
. /opt/sems/etc/default/sems
fi
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/opt/sems/usr/sbin/sems
...
LD_LIBRARY_PATH=/opt/sems/usr/lib/sems
export LD_LIBRARY_PATH
/opt/sems# ln -s /opt/sems/etc/init.d/sems /etc/init.d/sems-sbc
Then the SBC-SEMS can be started with
# /etc/init.d/sems-sbc start
and added to runlevels e.g. with update-rc.d sems
5. how to remove all this:
- stop SEMS with /etc/init.d/sems-sbc stop or kill -9 `cat
/var/run/sems/sems-sbc.pid`
- rm -rf /opt/sems
- rm /etc/init.d/sems-sbc
Happy hacking!
-------------------------------------------------------------------
Stefan
o Chris Michael on 01/06/2011 01:11 PM:
Hi Stefan,
Thanks for the response and the proposed solution. I'm in no way
technical and most of that went way over my head, but i'll get the
person who installed the platform to have a look into it.
Offering to post a how to is very kind of you, I'm sure it will
benefit other users of the platform also.
We were looking for an all-encompassing solution like sipwise
because we found using multiple platforms and writing patches and
custom script had a knock on effect on the overall stability and
security of the platform, but also worried that software updates to
the platforms would break any custom codes or configurations. If
this is the case with your solution it may be worth pointing it out
in the how to document so people can bear it in mind.
Thanks,
Chris
On 6 Jan 2011, at 11:32, Stefan Sayer wrote:
Hello,
you could easily have SEMS register to that 3rd party SIP
provider, as in ngcp you already have the necessary modules
installed (add registrar_client, reg_agent and uac_auth to
load_plugins, and configure the account in
/etc/sems/reg_agent.conf). But then SEMS registers with its
contact at port 5080. So, if the sipwise guys are not coming up
with a solution, and you are still interested, I might post a
howto using reg_agent and newer SEMS' sbc module, which lets you
do this kind of trunking easily.
Stefan
o Chris Michael on 01/06/2011 11:59 AM:
How simple to implement is this and when will it be available?
Without it we'll have to look into using a different platform
unfortunately.
On 5 Jan 2011, at 15:18, Tyrone Miles wrote:
Team,
This is much needed, and I would also like to see it in the next
release.
Thanks.
Date: Wed, 5 Jan 2011 13:44:08 +0100
From: [email protected] <mailto:[email protected]>
To: [email protected]
<mailto:[email protected]>
Subject: Re: [Spce-user] How to register 3rd party SIP service
provider.
On 01/05/2011 01:26 PM, Sailo VL Hruaia wrote:
Is it possible to register to 3rd party SIP service provider
for > > termination of calls using their service?
Doing a SIP REGISTER? Not at the moment, but should be easy to
implement. I'll discuss that with the SIP guys over here if we
can get
it into the next release maybe.
br,
daniel
_______________________________________________
Spce-user mailing list
[email protected] <mailto:[email protected]>
http://lists.sipwise.com/listinfo/spce-user
_______________________________________________
Spce-user mailing list
[email protected] <mailto:[email protected]>
http://lists.sipwise.com/listinfo/spce-user
------------------------------------------------------------------------
_______________________________________________
Spce-user mailing list
[email protected]
http://lists.sipwise.com/listinfo/spce-user
--
Stefan Sayer
VoIP Services Consulting and Development
Warschauer Str. 24
10243 Berlin
tel:+491621366449
sip:[email protected]
email/xmpp:[email protected]
--
Stefan Sayer
VoIP Services Consulting and Development
Warschauer Str. 24
10243 Berlin
tel:+491621366449
sip:[email protected]
email/xmpp:[email protected]
_______________________________________________
Spce-user mailing list
[email protected]
http://lists.sipwise.com/listinfo/spce-user
--
Stefan Sayer
VoIP Services Consulting and Development
Warschauer Str. 24
10243 Berlin
tel:+491621366449
sip:[email protected]
email/xmpp:[email protected]
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
