Hi,
Need help in setting the registration expiry timer at SER. I would like to
know the way we can enforce the registration expiry timer from server end.
Please update me on the configuration details.
Thanks in advance,
Ranganath B
Hi Fengbin!
Cc'ed to the openser list ...
fengbin schrieb:
> Hi,Klaus,
>
> How to use NULL cipher? Only setting in Openser is ok? I mean do I need
> to set NULL cipher at client site?
Usually the NULL cipher is not enabled (for security reasons). You have
to enable it on both sides, the server and the client. But if you use
the following approach you do not need it.
> And where to put xlog("L_ERR","message buffer: $mb"); anywhere in
> openser.cfg ?
Put it just in the beginning of the route block.
regards
klaus
> THX
> BR
>
>
> On 1/11/08, *Klaus Darilion* <klaus.mailinglists(a)pernau.at
> <mailto:klaus.mailinglists@pernau.at>> wrote:
>
> The capture file is not helpful, as it is encrypted. You could use NULL
> cipher to have plaintext inside the TLS connection to inspect the
> incoming SIP message, or add xlog("L_ERR","message buffer: $mb"); to see
> the whole incoming SIP request.
>
> regards
> klaus
>
> fengbin schrieb:
> > Hi,Klaus
> > Thank you for your reply.
> > The enclosed is the config file ,the pcap between client and
> server and
> > the log on the openser 's console.
> > Could you please take a look at them for me?
> >
> > THX
> > BR
> >
> >
> > On 1/10/08, *Klaus Darilion* <klaus.mailinglists(a)pernau.at
> <mailto:klaus.mailinglists@pernau.at>
> > <mailto:klaus.mailinglists@pernau.at
> <mailto:klaus.mailinglists@pernau.at> >> wrote:
> >
> > Can you show us the REGISTER request? (both, port 5060 and
> port 5061).
> >
> > Further show use your openser config
> >
> > regards
> > klaus
> >
> > fengbin schrieb:
> > >
> > > Hi,all
> > > I met a strange problem while I am testing TLS connection
> between
> > > minisip and openser.
> > > The following is my openser.cfg (part of that)
> > >
> > > .........
> > > fork=no
> > > log_stderror=yes
> > >
> > > # Uncomment this to prevent the blacklisting of
> temporary not
> > > available destinations
> > > #disable_dns_blacklist=yes
> > >
> > > # # Uncomment this to prevent the IPv6 lookup after v4
> dns lookup
> > > failures
> > > #dns_try_ipv6=no
> > >
> > > # uncomment the following lines for TLS support
> > > disable_tls = 0
> > > listen = tls: 10.11.57.197:5060
> <http://10.11.57.197:5060> <http://10.11.57.197:5060>
> > <http://10.11.57.197:5060>
> > >
> > >
> > > tls_verify_client = 1
> > > tls_method = TLSv1
> > > tls_certificate = "/usr/local/etc/openser//tls/user/user-
> > cert.pem"
> > > tls_private_key =
> > "/usr/local/etc/openser//tls/user/user- privkey.pem"
> > > tls_ca_list = "/usr/local/etc/openser//tls/user/user-
> calist.pem"
> > > tls_ciphers_list="NULL-SHA:NULL-MD5:AES256-SHA:AES128-SHA"
> > > ......
> > >
> > > When I set "tls:10.11.57.197:5061
> <http://10.11.57.197:5061> <http://10.11.57.197:5061> <
> > http://10.11.57.197:5061>" the
> > > registration never succeed. But if I set it to 5060 the
> registration
> > > over TLS is OK.
> > > I compared the log of two scenarioes and found the TLS
> session
> > both are
> > > OK,but the difference is that:
> > > when the port is 5061 there is an error of forwarding. but the
> > > forwarding is because openser think it's not the
> destination of
> > > the registration request. See bellow:
> > >
> > > Jan 10 16:46:56 [9199] DBG:rr:after_loose: No next URI
> found
> > > Jan 10 16:46:56 [9199] DBG:core:grep_sock_info:
> checking if
> > > host==us: 12==12 && [ 10.11.57.197
> <http://10.11.57.197> <http://10.11.57.197>
> > <http://10.11.57.197 <http://10.11.57.197>>] ==
> > > [10.11.57.197 <http://10.11.57.197>
> <http://10.11.57.197> <http://10.11.57.197>]
> > > Jan 10 16:46:56 [9199] DBG:core:grep_sock_info:
> checking if port
> > > 5061 matches port 5060
> > > Jan 10 16:46:56 [9199] DBG:core:check_self: host != me
> > > Jan 10 16:46:56 [9199] DBG:core:parse_headers:
> > flags=ffffffffffffffff
> > > Jan 10 16:46:56 [9199] DBG:tm:t_newtran: T on
> > entrance=0xffffffff
> > > Jan 10 16:46:56 [9199] DBG:core:parse_headers:
> > flags=ffffffffffffffff
> > > Jan 10 16:46:56 [9199] DBG:core:parse_headers: flags=78
> > > Jan 10 16:46:56 [9199] DBG:tm:t_lookup_request: start
> searching:
> > > hash=58073, isACK=0
> > > Jan 10 16:46:56 [9199] DBG:tm:matching_3261: RFC3261
> transaction
> > > matching failed
> > > Jan 10 16:46:56 [9199] DBG:tm:t_lookup_request: no
> > transaction found
> > > Jan 10 16:46:56 [9199] DBG:core:mk_proxy: doing DNS
> lookup...
> > > Jan 10 16:46:56 [9199] ERROR:tm:update_uac_dst: failed
> to fwd
> > to af
> > > 2, proto 1 (no corresponding listening socket)
> > > Jan 10 16:46:56 [9199] ERROR:tm:t_forward_nonack:
> failure to add
> > > branches
> > >
> > >
> > >
> > > With comparition to that when the port is set to 5060 the
> trace is :
> > >
> > > Jan 10 17:07:59 [9410] DBG:rr:find_next_route: No next
> Route
> > HF found
> > > Jan 10 17:07:59 [9410] DBG:rr:after_loose: No next URI
> found
> > > Jan 10 17:07:59 [9410] DBG:core:grep_sock_info:
> checking if
> > > host==us: 12==12 && [ 10.11.57.197
> <http://10.11.57.197> <http://10.11.57.197>
> > <http://10.11.57.197>] ==
> > > [ 10.11.57.197 <http://10.11.57.197>
> <http://10.11.57.197> <http://10.11.57.197>]
> > > Jan 10 17:07:59 [9410] DBG:core:grep_sock_info:
> checking if port
> > > 5060 matches port 5060
> > > Jan 10 17:07:59 [9410] DBG:core:grep_sock_info:
> checking if
> > > host==us: 12==12 && [10.11.57.197
> <http://10.11.57.197> <http://10.11.57.197>
> > <http://10.11.57.197>] ==
> > > [10.11.57.197 <http://10.11.57.197> <
> http://10.11.57.197> <http://10.11.57.197>]
> > > Jan 10 17:07:59 [9410] DBG:core:grep_sock_info:
> checking if port
> > > 5060 matches port 5060
> > > Jan 10 17:07:59 [9410] DBG:core:parse_headers:
> > flags=ffffffffffffffff
> > > Jan 10 17:07:59 [9410] DBG:core:parse_headers:
> flags=8000000
> > > Jan 10 17:07:59 [9410] DBG:core:parse_headers:
> > flags=ffffffffffffffff
> > > Jan 10 17:07:59 [9410] DBG:registrar:build_contact:
> created
> > Contact
> > > HF: Contact:
> > <sip:888@10.11.57.192:5061;transport=TLS>;expires=1000
> > >
> > >
> > >
> > > And there is no fwd needed then.So the error didnt occur.
> > >
> > > Its a little bit strange that when I set the port to
> 5061,why did
> > > openser check the port 5060?????
> > > Can anyone help me to figure it out?
> > > THX
> > > BR
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Fengbin
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users(a)lists.openser.org <mailto:Users@lists.openser.org>
> <mailto:Users@lists.openser.org <mailto:Users@lists.openser.org>>
> > > http://lists.openser.org/cgi-bin/mailman/listinfo/users
> >
> >
> >
> >
> > --
> > Fengbin
> >
>
>
>
>
> --
> Fengbin
>>> I would _really_ recommend to add this to the installations
instructions
on openxcap.org. Have a nice weekend! Sebastian
Done.
We will setup a read/write page for OpenXCAP deployment experiences.
Regards,
Adrian
Hi, I've been suffering an extrange issue and now I've realized why. It's
related to script variables and their duration.
I'm 90% sure that the behaviour is unexpected according to the doc so I've
open a bug containing an easy example:
https://sourceforge.net/tracker/index.php?func=detail&aid=1870301&group_id=…
My conclusion is that using script variables instead of AVP's can be risky in
certain cases. Opinions are welcome.
Best regards.
--
Iñaki Baz Castillo
Dear all
I finally found the mistake: My VMWare ESX server for virtualization is
not connected to the internet, my local PC was. It didn't come to my
mind ever before.
Although - I never saw it documented anywhere, that OpenXCAP needs
internet access for downloading the namespace files.
I would _really_ recommend to add this to the installations instructions
on openxcap.org.
Have a nice weekend!
Sebastian
________________________________
From: Schumann Sebastian
Sent: Friday, 11. January 2008 11:54 AM
To: users(a)openser.org
Subject: [OpenSER-Users] Strange OpenXCAP behaviour in
virtualizedenvironment
Dear all
This week, I tried again to bring up finally the OpenXCAP
server. I tried it first acc. the instruction on OpenXCAP.org on my
local virtual VMWare Server 1.0 (before, I always used virtualized ESX
server). It worked without major issues, meaning I could install lenny,
all required files even via apt-get and the OpenXCAP was running.
Surprising for me though, because it never worked yet.
Now, when I take _the same_ virtual disk and export it to VMWare
ESX server, I get the previously discussed errors:
Sep 25 17:01:21 openxcap openxcap[11876]: [-] Log opened.
Sep 25 17:01:21 openxcap openxcap[11876]: [-] Starting Open XCAP
0.9.3
Sep 25 17:01:27 openxcap openxcap[11876]: [-] Traceback (most
recent call last):
Sep 25 17:01:27 openxcap openxcap[11876]: [-] File
"/usr/bin/openxcap", line 56, in ?
Sep 25 17:01:27 openxcap openxcap[11876]: [-] from
xcap.server import XCAPServer
Sep 25 17:01:27 openxcap openxcap[11876]: [-] File
"/usr/lib/python2.4/site-packages/xcap/server.py", line 21, in ?
Sep 25 17:01:27 openxcap openxcap[11876]: [-] from xcap
import authentication
Sep 25 17:01:27 openxcap openxcap[11876]: [-] File
"/usr/lib/python2.4/site-packages/xcap/authentication.py", line 21, in ?
Sep 25 17:01:27 openxcap openxcap[11876]: [-] from
xcap.appusage import getApplicationForURI
Sep 25 17:01:27 openxcap openxcap[11876]: [-] File
"/usr/lib/python2.4/site-packages/xcap/appusage/__init__.py", line 466,
in ?
Sep 25 17:01:27 openxcap openxcap[11876]: [-] applications =
{'xcap-caps': XCAPCapabilitiesApplication(),
Sep 25 17:01:27 openxcap openxcap[11876]: [-] File
"/usr/lib/python2.4/site-packages/xcap/appusage/__init__.py", line 64,
in __init__
Sep 25 17:01:27 openxcap openxcap[11876]: [-]
self.xml_schema = etree.XMLSchema(xml_schema_doc)
Sep 25 17:01:27 openxcap openxcap[11876]: [-] File
"xmlschema.pxi", line 67, in etree.XMLSchema.__init__
Sep 25 17:01:27 openxcap openxcap[11876]: [-]
etree.XMLSchemaParseError: Document is not valid XML Schema
How can this be possible? I tried three times with three
different machines. They work in VMware Server but not in ESX server. I
don't find any answer at all neither can I imagine anyhow, how an
application error like this occurs running the program on the very same,
identical virtualized system with just two different virtualization
platforms around.
Anybody else has experiences in that, encountered somehow same
strange behaviour with the application or has any other advice? I would
really welcome every hint in somehow a direction to solve this. I didn't
plan to extend my virtual OpenSER testing platform with a local PC, but
it seems I have no other possibility so far...
Thanks for your help! A nice weekend to all of you.
Best regards
Sebastian
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good Evening,
I have a little question:
I have users with usernames and 10 phone numbers from my SIP/PSTN
provider.
I have a dbaliases table for incoming calls, in order to redirect the
0xxxxxxxxx number to an user.
0xxxxxxxx1 => bob
I would like for outgoing calls to replace the user by the telephone
number in the From: Header.....
bob => 0xxxxxxxx1
Any idea how to do it?
Thanks,
Marc Leurent
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHh6ssN4+o+2LtdFwRApxIAKCxqefV7OLejg1Xw6mwre5Yy3jYTQCeM66R
bAjagfV/6aoN43hPQcMeKMM=
=DQe8
-----END PGP SIGNATURE-----
Greetings,
I have a strange problem using OpenSER 1.3.x with nathelper.
Two ethernet interfaces:
eth0 = 192.168.0.0/24
eth1 = outside.ip/29
For some reason, no matter what I do to mangle the requests with
nathelper's functions, the packet is *always* sent out of eth1 with
the *source address* of the machine's eth0. Obviously, the response
from the far-end SIP peer never gets back.
The packet does physically go over eth1, I know that much from packet
captures. I don't even see how this is possible; when OpenSER issues
a packet, shouldn't it originate according to the machine's routing
table, take the most specific route, and consequently, adopt the right
source address?
What gives?
I have OpenSER 'listening' on both interfaces, and have tried both on and
off with this setting.
Thanks,
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : +1-678-954-0670
Direct : +1-678-954-0671
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
does anybody know, if openser+rtpproxy are able to detect rtp-timeouts
and react on them? It would be good for billing.
regards
Helmut
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHhjWa4tZeNddg3dwRAmZcAJkBmJGh6b2qt/6NbFri0mBZU9BwPQCeNYNS
Pb+u2IWB4Xp2K8G9fHkQKyo=
=MxAh
-----END PGP SIGNATURE-----
Hi,
How can one replace the ruri host part with the usage of attr2uri method?
One can change the domain part with the usage of "domain" param
but this leaves the port not changed. I would like to replace the whole
host part together with port value.
Maybe this can be done other way round?
Thanks in advance for any help.
Bests
-tomasz