[Devel] Crash with openser 1.1.0 and TLS clients

Klaus Darilion klaus.mailinglists at pernau.at
Fri Nov 24 11:24:44 CET 2006

Christophe Irles wrote:
> Hi Klaus,
> Thank for your inputs.
> Server side - version:
> 	openser-1.1.0-tls
> 	openssl-0.9.7f-7.10

Hmm - I'm using 0.9.7.e

> Client side - version:
> 	minisip r2891
> 	openssl-0.9.8b
> About the buggy User Agent, to be sure to understand well, the pb comes from
> the line 55.
> The ACK must be:
> ACK sip:810 at;transport=TCP SIP/2.0
> Instead of:
> ACK sip:810 at SIP/2.0
> Is it correct ? I will send a mail to the minisip development team.

Yes, correct - all the parameters from the Contact URI must be copied to 
the request URI.

> TLS Dump analysis:
> - 3 SSL connections: I thought openssl will reuse the previous connections
> and not create a new one to send the INVITE to the second client. In this
> situtation the client 2 is never reached if he is behind a NAT, isn't it ?
> The problem is the same in TCP.

Yes. Let's take a look at client 2 (TCP dump)
REGISTER sent from .23:2497
Contact: .23:5060

Thus, when openser sends the INVITE to client 2, it will compare the 
destination (.23:5060) with the current open TCP connections. As there 
is no TCP connection to socket .23:5060 it will open a new one.

Eyebeam solve this problem with re-REGISTRATION:
2. Check rport & received address in Via header of 200 OK response
3. if rport/received is different than the contact used for 
registration, then
   4. unregister
   5. register with a contact construced from the rport+received.

In openser you can handle this with the command force_tcp_alias:

This will add the port from the Via header as alias - thus openser 
should route the call through the existing TCP connection. But I think 
this can have strange problems - e.g. if 2 minisips are behind the same 
NAT. Both use local port 5060 (in contact), thus the alias ip:5060 would 
be the same for both.

But when using NAT traversal and fix_nated_register, openser should also 
save the public socket. Thus, after lookup(), the d-URI should contain 
the public socket for which an established TCP connection should be found.**

**Not sure about this in detail, but it would be strange if it wouldn't 
be this way.


> As soons as possible I will test again as you suggest with the all traffic.
> Thanks,
> Christophe

More information about the Devel mailing list