14 Nov
2006
14 Nov
'06
9:58 p.m.
Hi Klaus,
the tcp connections are hashed based on destination IP and port - when a
messaged is to be relaid via TCP, the tcp manager looks to see if an
existent connection already exists or not, and if yes, it reuses it.
yes, running in debug mode will be useful as it provides more info about
the TCP management - also compiling with EXTRA_DEBUG flag will give even
more info about the TCP connection lookup.
regards,
bogdan
Klaus Darilion wrote:
I have no idea.
First try setting the eyebeam's URI in openser.cfg manually (using
avp_pushto or rewriteuri) and watch openser's behaviour. If it still does
not work, then it is something related to lookup - maybe there is a
pointer stored in location table to the TCP connection.
Also you can try the hard way: increase debug level and compare the log
message, and take a look at the source code to find the problem :-(
regards
klaus
On Fri, October 20, 2006 12:44, Pat wang said:
Hi Klaus,
I forgot to say that the R-URI is the same as the one as in the Contact
URI.
The Eyebeam is registered with a contact URI as:
user1@192.168.100.1:port1;rinstance=xxx;transport=tls
and the Request-URI received on OpenSER matches exactly as the Contact
URI.
What I am trying to do is to have OpenSER as TLS to UDP protocol converter
to a 3rd party proxy without TLS feature. I need the 3rd party proxy
keeps
record of the TLS clients by configuring OpenSER forward the REGISTER from
the TLS client through UDP. If a call is from UDP client to TLS client the
3rd party proxy does the replacement of RURI and proxy it to OpenSER
through
UDP. What I expect is OpenSER uses the existing TCP session to proxy the
INVITE to the TLS client. Any new suggestiongs?
Thanks,
Patrick
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
From: Klaus Darilion
<klaus.mailinglists(a)pernau.at>
To: Pat wang <wangyu39(a)hotmail.com>
CC: users(a)openser.org
Subject: Re: [Users]Can OpenSER uses same TCP session from the
registration
in some TLS case?
Date: Fri, 20 Oct 2006 08:43:54 +0200
Pat wang wrote:
_________________________________________________________________
All-in-one security and maintenance for your PC. Get a free 90-day trial!
http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://ww…
Hi,
I am working on the TLS with OpenSER and I found an something
interesting.
If an INVITE received by OpenSER with a Request-URI of the client AOR
then
OpenSER proxy the request via the same TCP session established during
registration. If the INVITE has a Request-URI of the client's contact
URI
then OpenSER start a new TCP session.
For example:
One Eyebeam registers with AOR as: user1(a)tlstest.com and has a contact
URI
of user1(a)192.168.100.1. When an INVITE contains a RURI as
the contact must be at least user1(a)192.168.100.1;transport=TLS, and
usually
also a port is specified.
Thus I guess it happens as you directly dial the contact without
transport
parameter and port.
regards
klaus
PS: Of course a dump would help:
"ngrep -W byline -t port 5060"
if you use TLS use port 5061 and use the NULL encryption schema in TLS
settings.
>user1(a)tlstest.com then OpenSER look up the location table and replace it
>with the user1(a)192.168.100.1 then proxy it via the same TCP session as
>the
>one during the registration. If an INVITE already has RURI as
>user1(a)192.168.100.1 then OpenSER proxy this INVITE by starting a new TCP
>session and Eyebeam does not accept the new session. The call will be
>failed in this case. I can't find any solution to fix this issue. Could
>someone know this issue please give some advice?
>
>Thanks,
>
>Patrick
>
>_________________________________________________________________
>All-in-one security and maintenance for your PC. Get a free 90-day
>trial!
>http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail
>
>
>
>_______________________________________________
>Users mailing list
>Users(a)openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
>
>