Unauthorized call and program exceptions

Feb 9, 2010 at 3:06 PM

Hi, I am starting to feel a bit stupid, but I have failed to get a second sipsorcery server working. We have one installation that works as expected but since I need a separate test environment, I decided to install it on my workstation. I think I followed the instructions correctly and the server starts up. I can create the accounts and the user agents can register. All looks fine until I try to make a call.

With Wireshark, I see the INVITE message coming in on the network card and in the output of the server, running in console mode, I see that it receives the message. But it says that the call is not authenticated and that it is responding with unauthorised. I see no such message coming out on the network card, but instead the server reports an exception.

I am thinking that the initial INVITE does not have any authentication info and that the server is supposed to answer with unauthorised. This would then cause the user agent to send a new INVITE complete with authentication info. Unfortunately this message never reaches the user agent. It seems as if the message is, in fact, sent to localhost and the server chokes on receiving a message of that type. Looking at the message dumps in the log shows that, at least, the to header is blank!

Does this sound like a reasonable explanation? If so, what kind of misconfiguration do you think could cause this behaviour? When I cancel the call or when the user agent registers, the OK messages are sent where they should.

Log:

GotRequest processing time=62.5ms, script time=62.5.
as (44:05:609): AppServerCore INVITE received, uri=sip:test02@tusip.sr.se, cseq=1.
as (44:05:734): Call not authenticated for test01@tusip.sr.se, responding with Unauthorised.
Exception StatelessProxyCore GotResponse. expected object, got NoneType
pr: Exception StatelessProxyCore GotResponse. expected object, got NoneType
Exception SIPTransport SIPMessageReceived. expected object, got NoneType
Microsoft.Scripting.ArgumentTypeException: expected object, got NoneType
   at SIPSorcery.Servers.StatelessProxyCore.GotResponse(SIPEndPoint localSIPEndPoint, SIPEndPoint remoteEndPoint, SIPResponse sipResponse)
   at SIPSorcery.SIP.SIPTransport.SIPMessageReceived(SIPChannel sipChannel, SIPEndPoint remoteEndPoint, Byte[] buffer)
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bKA4783BF6A1B5C97170A89BE9B7FEEA47B99C3DA
Via: SIP/2.0/UDP 134.25.195.60:5060;branch=z9hG4bKb9db3c91cb0b48088fd408936485d290
Via: SIP/2.0/UDP 134.25.222.132:2063;branch=z9hG4bK-dggh4z9iinyp
To: 
From: "test01" ;tag=z689a0w4y2
Call-ID: 3c34d0ab6b6c-j2gqi2a1zncy@snom360-000413236EDC
CSeq: 1 INVITE
Content-Length: 0

Exception StatelessProxyCore GotResponse. expected object, got NoneType
pr: Exception StatelessProxyCore GotResponse. expected object, got NoneType
Exception SIPTransport SIPMessageReceived. expected object, got NoneType
Microsoft.Scripting.ArgumentTypeException: expected object, got NoneType
   at SIPSorcery.Servers.StatelessProxyCore.GotResponse(SIPEndPoint localSIPEndPoint, SIPEndPoint remoteEndPoint, SIPResponse sipResponse)
   at SIPSorcery.SIP.SIPTransport.SIPMessageReceived(SIPChannel sipChannel, SIPEndPoint remoteEndPoint, Byte[] buffer)
SIP/2.0 401 Unauthorised
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bKA4783BF6A1B5C97170A89BE9B7FEEA47B99C3DA
Via: SIP/2.0/UDP 134.25.195.60:5060;branch=z9hG4bKb9db3c91cb0b48088fd408936485d290
Via: SIP/2.0/UDP 134.25.222.132:2063;branch=z9hG4bK-dggh4z9iinyp
To: 
From: "test01" ;tag=z689a0w4y2
Call-ID: 3c34d0ab6b6c-j2gqi2a1zncy@snom360-000413236EDC
CSeq: 1 INVITE
WWW-Authenticate: Digest realm="tusip.sr.se",nonce="13016138422089749856"
Content-Length: 0


GotRequest processing time=31.25ms, script time=31.25.
Resending final response for INVITE, sip:test02@tusip.sr.se, cseq=1.
Exception StatelessProxyCore GotResponse. expected object, got NoneType
pr: Exception StatelessProxyCore GotResponse. expected object, got NoneType
Exception SIPTransport SIPMessageReceived. expected object, got NoneType
Microsoft.Scripting.ArgumentTypeException: expected object, got NoneType
   at SIPSorcery.Servers.StatelessProxyCore.GotResponse(SIPEndPoint localSIPEndPoint, SIPEndPoint remoteEndPoint, SIPResponse sipResponse)
   at SIPSorcery.SIP.SIPTransport.SIPMessageReceived(SIPChannel sipChannel, SIPEndPoint remoteEndPoint, Byte[] buffer)
SIP/2.0 401 Unauthorised
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bKA4783BF6A1B5C97170A89BE9B7FEEA47B99C3DA
Via: SIP/2.0/UDP 134.25.195.60:5060;branch=z9hG4bKb9db3c91cb0b48088fd408936485d290
Via: SIP/2.0/UDP 134.25.222.132:2063;branch=z9hG4bK-dggh4z9iinyp
To: 
From: "test01" ;tag=z689a0w4y2
Call-ID: 3c34d0ab6b6c-j2gqi2a1zncy@snom360-000413236EDC
CSeq: 1 INVITE
WWW-Authenticate: Digest realm="tusip.sr.se",nonce="13016138422089749856"
Content-Length: 0

Coordinator
Feb 9, 2010 at 11:27 PM

Hi,

There's a problem in your SIP Proxy python control script, proxyscript.py. Within that script's SIP response processing it's attempting to reference a null object which generates the exception. The proxy control script is the hardest part of configuring sipsorcery as it needs to take into account whether the machine running it is behind a NAT, what the private IP address prefix is, whether to mangle outgoing Contact headers etc.

If you haven't already try using the latest Python control script from http://sipsorcery.codeplex.com/SourceControl/changeset/view/38979#299729. I updated it recently to try and make it work better in different deployments. The only thing you should need to edit in it are the variables in the top section with hard coded IP addresses m_proxySocketInternal etc.

Regards,

Aaron

 

Feb 12, 2010 at 1:11 PM
Edited Feb 12, 2010 at 1:19 PM

Thanks. I tested the latest version of the proxy script, but that seems to require a different version of sipsorcery - it passes only four parameters to SendTransparent() whereas the v1.1 script passes six. However, after some fiddling with the old proxy script I managed to get it one step further. I removed thing about detecting local networks, preventing it from ever using the "publicip". Then I see in the log that it starts processing the call, running the dial plan etc. It still fails to complete the call, but I am starting to think that the problem really lies with the publicip and the detection thereof.

In our first setup, the network is completely local, i.e. ALL addresses start with "10.", this includes every UA. Here things worked after we set the dial plan to not mangle any addresses.

In my new setup, all IP addresses are public, they start with "134.", however, Internet can not be reached from any of our networks. This means that the default STUN-server, "stun.xten.com", can not be reached. I tried to disable this by simply leaving the "STUNServerHostname" option blank in sipsorcery-appserver.exe.config.

The STUN-server was disabled in the same way in our first setup, but since all addresses there are "local", the publicip is never used anyway. Now, in the new setup, I assume that it does try to use publicip and that this never gets properly initialised because I removed the STUN server.

Does this make sense? Can I manually specify a public IP address for the server to use?

EDIT: I tried to completely remove the STUNServerHostName directive but get the same result.

Coordinator
Feb 14, 2010 at 10:58 AM

You can set the public IP address by specifying a PublicIPAddress setting in the sipproxy node.

You're right about some of the methods that the proxy runtime script uses having changed. If the fix above doesn't work it's probably worth trying the new v1.2 release.