Hi! I have the following problem
openser1 <-----TLS----> openser2
-----INVITE------------>
<------403--------------
openser1 does not like the 403 response (generated with sl_send_reply()).
tcp_read_headers: ERROR: no clen, p=A
ERROR: tcp_read_req: bad request, state=4, error=4 buf: SIP/2.0 403 do
not reuse this TLS connection ^M Via: SIP/2.0/TLS
10.10.0.41:5063;branch=z9hG4bK2ac3.a346b0f3.0^M Via: SIP/2.0/UDP
10.10.0.41;branch=z9hG4bK2ac3.54290e8.0^M Via: SIP/2.0/UDP
10.10.0.205:7836;branch=z9hG4bK-d87543-4f7f2765412a2d12-1--d87543-;rport=7836^M
To:
<sip:+43201@proxy1.ienum.labs.nic.at>;tag=10ad1f9ed36b57d334f8c84f393c0304.7a7e^M
From: <sip:user101@proxy1.ienum.labs.nic.at>;tag=ca36697e^M Call-ID:
6c71b8428247c758@d2lnd2Ft^M CSeq: 2 INVITE^M server_header: BP 2^M
Content-Length: 0^M Warning: 392 10.10.0.42:5063 "Noisy feedback tells:
pid=2661 req_src_ip=10.10.0.41 req_src_port=32918
in_uri=sip:+43201@bp2.ienum.labs.nic.at;transport=tls
out_uri=sip:+43201@bp2.ienum.labs.nic.at;transport=tls via_cnt==3"^M ^M
parsed: SIP/2.0 403 do not reuse this TLS connection ^M
Does someone knows this problem? If not, I will debug next week :-(
regards
klaus
Hello all,
we started using ISDN-SIP gateways where you can specify one digest-id in
authentification header for multiple caller ids. Now, there seems to be a
problem with security if you don't bind caller-id with ip address or domain.
As we cannot know from wich IP (domain) our call will come from we cannot
bind it to certain IP (domain). There should be some way to specify which
caller-ids (usernames) should relate to auth-id. Similar direction i found
in ser admin's guide:
"There may be a need for a more complex relationship between From/To
username and digest id. For example, providers with an established
user/password database may wish to keep using it, whereas permitting users
to claim some telephone numbers in From. To address such needs generally,
there needs to be a 1:N mapping between digest id and all usernames that are
acceptable for it. This is being addressed in a newly contributed module
"domain", which also addresses more generally issues of domain matching for
multidomain scenarios."
Still, i didn't found how how could i use domain module for this. What
approach other people use in such case?
Viktor
Hi Manoj,
I downloaded the same tarball but I followed the directions from the
INSTALL file within (these are usually more up to date)
This is what I did on CentOS 4.2:
Start with setting your SIP_DOMAIN environment variable in
~/.bash_profile:
SIP_DOMAIN=your.server.domain.com
export SIP_DOMAIN
I found that many ser utilities (serctl particularly) expect this to be
set.
Extract the tarball under /var/www/ and add a link to serweb for easy
upgrading to later versions:
cd /var/www
tar xzf serweb-0.9.4.tar.gz
ln -s serweb-0.9.4 serweb
Create /etc/httpd/conf.d/serweb.conf to avoid messing up your main
apache conf file:
Alias /serweb /var/www/serweb/html
<Location /serweb>
Order deny, allow
Deny from all
Allow from 127.0.0.1
Allow from 192.168.0.0/16
</Location>
Edit /var/www/serweb/config/config_data_layer.php and set your MySQL
credentials for admin as you entered them with the ser_mysql.sh script.
If you don't know what they are set to, execute this query: 'select
username, domain, password from ser.subscriber' in your favourite MySQL
client. If you used the default ser/heslo, then these are set correctly
in the PHP file already. Confirm that the domain is the same as your
SIP_DOMAIN variable.
The /var/www/serweb/config/config_paths.php is where you set the root
path. You need to change this if you set a path in serweb.conf that is
different from /serweb.
You will have to have a good read through
/var/www/serweb/config/config.php to see if you want any of the stuff
mentioned there. I didn't need to change it.
(re)start apache and browse to
http://your.server.domain.com/serweb/admin. If you enter admin it will
automagically be expanded to admin(a)your.sip.domain and you can enter the
password as heslo (or whatever you changed it to).
Hope this helps,
Bart...
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of mkumar(a)mantragroup.com
Sent: 30 January 2006 11:37
To: serusers(a)lists.iptel.org
Subject: [Serusers] Unable to configure serweb-0.9.4
Hi All,
I downloaded serweb from
ftp://ftp.berlios.de/pub/ser/0.9.4/contrib/serweb-0.9.4.tar.gz and I am
trying
to install serweb from instructions given in
http://www.iptel.org/ser/doc/ser-howto/ser-Howto.html#AEN256. I executed
tar
-xvzf serweb-0.9.4.tar.gz and afterwards as per the instructions my next
step
is to modify /user_interface/prepend.php, but I could not find
user_interface
directory itself, I searched for it and I could not find it in my UNIX
box
itself. Is there any bug with serweb-0.9.4.tar.gz or we do not need
user_interface directory itself for serweb-0.9.4? Can someone please
help me
and guide me to configure serweb-0.9.4.
Thanks,
Manoj.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Remarque : message transféré en pièce jointe.
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
Hi All,
I downloaded serweb from
ftp://ftp.berlios.de/pub/ser/0.9.4/contrib/serweb-0.9.4.tar.gz and I am trying
to install serweb from instructions given in
http://www.iptel.org/ser/doc/ser-howto/ser-Howto.html#AEN256. I executed tar
-xvzf serweb-0.9.4.tar.gz and afterwards as per the instructions my next step
is to modify /user_interface/prepend.php, but I could not find user_interface
directory itself, I searched for it and I could not find it in my UNIX box
itself. Is there any bug with serweb-0.9.4.tar.gz or we do not need
user_interface directory itself for serweb-0.9.4? Can someone please help me
and guide me to configure serweb-0.9.4.
Thanks,
Manoj.
FYI
klaus
-------- Original Message --------
Subject: [Serdev] TLS status update
Date: Mon, 30 Jan 2006 11:50:26 +0100
From: Jan Janak <jan(a)iptel.org>
To: serdev(a)iptel.org
Hello,
here is an interim update on the state of the TLS code:
Current status
--------------
There is a new module called TLS in the cvs repository. The module
attempts to merge the TLS code from experimental cvs module (maintained
by Cesc) and Andrei's implementation, to get the best of both.
Furthermore the module contains some new functions for script based
certificate verification.
The TLS module is much more stable than the original implementation. The
original (experimental) code works only when there are no simultaneous
TLS connections/attempts. The original code would either crash or block
SER in seconds under heavy load so it is not really suitable for
production use.
The code in TLS module is much more stable, it contains several fixes
(icluding fix of openssl) and does not seem to crash even under load
Unfortunately we discovered a problem during testing of TLS code
which can lead to SER being blocked for the duration of tls_send_timeout
interval. After that time it would recover. Andrei can probably
elaborate more on this issue, but as far as I know there is no easy way
to fix it.
In conclusion the TLS code in the tls module is more stable than the
original code from experimental but is not yet ready for production
deployments (unless you can risk SER being blocked for some time).
Installation
------------
To use the module you need to patch SER with tls-core.patch. The patch
is in tls module directory. After applying the patch compile SER with
TLS=1 appended to the make command. This is a temporary inconvenience,
we are working on eliminating the need for the patch.
TLS select functions
--------------------
The current HEAD SER version contains a mechanism which we internaly
call the "select" framework. The select framework makes it possible to
register functions from modules which can extract pieces of information
from the SIP message, transports or IP datagrams. Select functions are
denoted by @ character in the configuration file. The name of the select
consists of tokens (optionally followed by a number in square brackes)
and denoted by ., for example:
@contact[2].uri.params.transport
Would return the value of transport URI parameter from the second
Contact URI in the SIP message.
TLS module makes use of this mechanism and contains several functions
that can be used to retrieve TLS related information in the
configuration script. Currently implemented are the following functions:
@tls -- String description of the TLS layer
@tls.version -- Protocol version being used
@tls.desc -- The same as @tls
@tls.cipher -- Cipher name being used
@tls.cipher.bits -- Number of bits used for encryption
@tls.peer -- Peer certificate subject common name
@tls.me -- Local certificate subject common name
@tls.peer.subject -- same as @tls.peer
@tls.peer.issuer -- Peer certificate issuer common name
@tls.peer.verified -- True if peer cert has been verified
@tls.{peer,my}.version -- Peer/local certificate version
@tls.{peer,my}.sn -- Peer/local certificate number
@tls.{peer,my}.not_before -- Certificate validity start
@tls.{peer,my}.not_after -- Certificate validity end
@tls.{peer,my}.email -- Email address from subj alternative name
@tls.{peer,my}.host -- DNS anme from subj alternative name
@tls.{peer,my}.uri -- URI from subj alternative name
@tls.{peer,my}.ip -- IP address from subj alternative name
@tls.{peer,my}.{subj,issuer}.locality -- locality component
@tls.{peer,my}.{subj,issuer}.country -- Issuer/subject country
@tls.{peer,my}.{subj,issuer}.state - Issuer/subject state
@tls.{peer,my}.{subj,issuer}.organization -- Subject/issuer
organization
@tls.{peer,my}.{subj,issuer}.unit - Subject/issuer organizational
unit
I will send details description of the functions in a separate email.
SSL certificate based authentication
------------------------------------
The functions can be used to implement SSL certificate based
authentication in the configuration script:
if (proto == TLS && @tls.peer != "Bob") {
sl_reply("403", "Forbidden");
break;
}
This will reject any request received through TLS unless the client
provides a client certificate which has subject common name set to
"Bob".
Select @tls is useful for storing information about the TLS connection
(the string can be stored in accounting table, for example, appended to
the outgoing message as a header, and so on).
Multi-domain configuration
--------------------------
The original (experimental) code contained the support for multi-domain
configuration. This mechanism was extended a little bit in the tls
module. In addition to server based TLS domains there is also
preliminary support for TLS client domains. TLS client domains are used
when SER attempts to connect to a remote party using TLS. This makes it
possible to configure different TLS client certificates for different
destinations.
In addition to that almost all TLS parameters can be now set on
per-domain basis. This includes:
- Certificate file
- Private key file
- Enable/disable certificate verification
- Certificate verification depth
- CA file
- Request/do not request certificate from peer
- Cipher list
- TLS method
TLS domains are identified using IP and port, this is the destination IP
and port of the TLS connections, in server TLS domains this must be one
of the IP and port configured through listen directives. In TLS client
domains this is the IP and port of the remote peer.
There is always one default server domain and one default client domain.
These are used when no matching server/client domain can be found for
IP/port pair.
TLS domains are configured through modparams, most tls modparams accept
the parameter value with the following syntax:
<ip>:<port>=<value.
If no IP and port has been specified then the parameters of the default
domain are set:
modparam("tls", "method", "1.2.3.4:5090=SSLv23")
modparam("tls", "verify_certificate", "1")
modparam("tls", "require_certificate", "0")
modparam("tls", "private_key", "/usr/local/etc/ser/alice_prik.key")
modparam("tls", "private_key", "1.2.3.4:5090=key.pem")
modparam("tls", "ca_list", "/usr/local/etc/ser/rootca.cert.pem")
modparam("tls", "certificate", "/usr/local/etc/ser/alice_cert.crt")
modparam("tls", "handshake_timeout", 120)
modparam("tls", "send_timeout", 120)
modparam("tls", "tls_log", 2)
This configuration is somewhat suboptimal and may change yet. Currently
there is no possibility to configure TLS client domains (it will be
added soon).
Example configuration
---------------------
Here is a configuration example which demonstrates a couple of
interesting things that can be done with the TLS module, XMLRPC
management interface and new serctl tools. This configuration file
snippet makes it possible to run serctl remotely. It uses the XMLRPC
procotol which is encrypted using TLS. Futhermore TLS certificate
authentication is used so only people having a correct client
certificate are allowed to execute the kill command (this command will
stop ser):
loadmodule "./modules/tls/tls.so"
loadmodule "./modules/sl/sl.so"
loadmodule "./modules/xmlrpc/xmlrpc.so"
listen=tls:1.2.3.4:5061
modparam("tls", "method", "SSLv23")
modparam("tls", "verify_certificate", "1")
modparam("tls", "require_certificate", "0")
modparam("tls", "private_key", "/usr/local/etc/ser/alice_prik.key")
modparam("tls", "ca_list", "/usr/local/etc/ser/rootca.cert.pem")
modparam("tls", "certificate", "/usr/local/etc/ser/alice_cert.crt")
route {
if (proto == TLS && (method == "POST" || method == "GET")) {
create_via(); # XMLRPC requests do not contain via, create it
if (!(a)tls.peer.verified) {
# Client did not provide certificate or it is not valid
xmlrpc_reply("400", "Unauthorized");
break;
}
if (@xmlrpc.method == "core.kill") {
# Make sure the client has the permission to execute the
command
if (@tls.peer != "SER-Killer") {
xmlrpc_reply("400", "Access to core.kill denied");
break;
}
}
dispatch_rpc();
break;
}
}
To be done
----------
There is still few things that are not yet done:
- @Cesc: Do we need the function set as verify_callback ? As far as
I know there is an internal representation in openssl. If we need it
then where do we get the verify_depth from (it can be different in
different domains)
- @Cesc: A couple of openssl parameters have different values, could you
check that nothing important is missing ?
- Currently only keys without passhprase would work, because SER has
no controlling terminal anymore when executing mod_init and child_init
module functions (this is where private keys are loaded)
Is this feature or bug ? Should we have support for private keys
protected by passphrase (requires human intervention when starting ser)
- The modparam syntax needs changes to support client domains
- TLS can block SER
- Support for revocation lists
- Should we generate SER CA in a script (possibly called from package
pre-init scripts) ? How do we make management of thousands of client
certificates easy ?
Jan.
_______________________________________________
Serdev mailing list
Serdev(a)iptel.org
http://mail.iptel.org/mailman/listinfo/serdev
Hi Suvendu,
yes, it works, but what about the autorization ?
In your case any softphone can register wich your proxy.
In real world it is a bad idea. I tired to forward the REGISTER request
only it the client is correctly authorized.
-- cut ---
if (is_method("REGISTER")) {
xlog("L_INFO", "REGISTER <$rm> r-uri <$ru>\n");
if (!www_authorize("voip.globaltel.sk", "subscriber")) {
www_challenge("voip.globaltel.sk", "1");
return;
}
if (!save("location")) {
sl_reply_error();
return;
}
# t_relay_to_udp("10.1.1.115", "5060");
t_replicate_udp("10.1.1.115", "5060");
return;
} else {
--- cut ---
To the server 10.1.1.115 is send REGOSTER REQ with full Digest informations. The 10.1.1.115 reject this
with "401 unanuthorized".
Can any one tell me how to redistibute REGISTER REQ (successfull) accross network? I can't share
SER database or have *(realtime). I have to do it only using SIP signaling.
best regards
hudecof
Suvendu Sethi wrote:
> Hi Jose,
>
> IP phone also allows you to configure for multiple
> VoIP controller servers but what I wanted was
> configuring 1 channel for multiple servers.
>
> It works fine now with the code which I pasted
> earlier.
>
> Cheers,
> Suvendu
>
>
> --- Voipers Portugal <voipers(a)gmail.com> wrote:
>
>
>>Not sure about that IP phone, but a Softphone allows
>>you to add multiple
>>server, so you can register with as many as you wish
>>(and the softphone
>>supports).
>>
>>Jose Simoes
>>
>>
>>On 1/17/06, Suvendu Sethi <suvenduji(a)yahoo.co.in>
>>wrote:
>>
>>>Hi All,
>>>
>>>Is it possible to register 1 IP phone with
>>
>>multiple
>>
>>>VoIP controllers?
>>>
>>>I want to configure 1 port on Cisco 7940 phone to
>>>register with SER proxy server and then forward
>>
>>the
>>
>>>registration request to 2 other Aspect VoIP
>>>controllers for registration.
>>>
>>>I am running SER 0.8.14 on linux.
>>>
>>>I tried the following option but it is registering
>>>with only 1 VoIP controller.
>>>
>>>if (method=="REGISTER")
>>>{
>>>save("location");
>>>rewritehost("10.248.13.77");
>>>forward(10,248,13,77,5060);
>>>rewritehost("10.248.13.66");
>>>forward(10,248,13,66,5060);
>>>break;
>>>};
>>>
>>>Can you help me on this please?
>>>
>>>Many thanks in advane.
>>>
>>>Cheers,
>>>Suvenduji
>>>
>>>
>>>Send instant messages to your online friends
>>
>>http://in.messenger.yahoo.com
>>
>>>_______________________________________________
>>>Serusers mailing list
>>>serusers(a)lists.iptel.org
>>>http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>
>
>
> Send instant messages to your online friends http://in.messenger.yahoo.com
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
--
"The box said 'Requires Windows 95, NT, or better,' so I installed Linux."
Hi as sugested here it goes ;) Sorry for doubling posting.
Elton Machado wrote:
Hi,
I'm getting a problem with nathelper and rtpproxy, somethimes happens
that rtpproxy core dumps, and I'm trying to understand why.
Maybe I have some mistake in my nathelper configuration with the force
rtp proxy. I'm using the cvs version of rtpproxy.
The result of dumps is:
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `rtpproxy'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 ishostseq (ia1=0xbfbfa3f0, ia2=0x0) at rtpp_util.c:48
48 if (ia1->sa_family != ia2->sa_family)
Another thing how is possible from ser or openser to control, in case
of rtproxy borked out I realive the process again?
Any help will be appreciated.
Regards,
Elton
_______________________________________________
> Devel mailing list
> Devel(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>
>
-----Mensagem original-----
De: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Enviada: segunda-feira, 30 de Janeiro de 2006 13:19
Para: Elton Machado
Cc: 'devel'
Assunto: Re: [Devel] Rtpproxy coredumps :(
Hi Elton!
You should post your bugreport also to the ser users list. This is were the
developer (Maxim) is active.
regards
klaus
Hi as sugested here it goes ;) Sorry for doubling posting.
Elton Machado wrote:
Hi,
I'm getting a problem with nathelper and rtpproxy, somethimes happens
that rtpproxy core dumps, and I'm trying to understand why.
Maybe I have some mistake in my nathelper configuration with the force
rtp proxy. I'm using the cvs version of rtpproxy.
The result of dumps is:
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `rtpproxy'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 ishostseq (ia1=0xbfbfa3f0, ia2=0x0) at rtpp_util.c:48
48 if (ia1->sa_family != ia2->sa_family)
Another thing how is possible from ser or openser to control, in case
of rtproxy borked out I realive the process again?
Any help will be appreciated.
Regards,
Elton
_______________________________________________
> Devel mailing list
> Devel(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>
>
-----Mensagem original-----
De: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Enviada: segunda-feira, 30 de Janeiro de 2006 13:19
Para: Elton Machado
Cc: 'devel'
Assunto: Re: [Devel] Rtpproxy coredumps :(
Hi Elton!
You should post your bugreport also to the ser users list. This is were the
developer (Maxim) is active.
regards
klaus
