Provisioning Service error for version 1.2 on mono

Discussions about using SIP Sorcery on your own computer/server
wildsip
Posts: 23
Joined: Sun Jun 19, 2011 2:42 am

Provisioning Service error for version 1.2 on mono

Post by wildsip » Sun Jun 19, 2011 3:07 am

I have got Sipsorcery v1.2 running on Debian Squeeze 6.0 (using mono-complete package) and XML configuration files, except for one error, which is:

Exception starting Provisioning hosted service. Value must be positive integer.

This error causes the silverlight user interface to not work.

This error seems to occur in the code of SIPAppServerDaemon.cs, where the WCF services are initialized. Any idea what this integer could be ? :


region Initialise WCF services.

try
{
...
logger.Debug("Provisioning hosted service successfully started on
}
catch (Exception excp)
{
logger.Warn("Exception starting Provisioning hosted service.

}

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Provisioning Service error for version 1.2 on mono

Post by Aaron » Sun Jun 19, 2011 12:23 pm

On Windows there's a need to enable a WCF end point (which is what the provisioning hosted service is) before an application can use it. The command is:

Code: Select all

httpcfg set urlacl /u http://+:8080/ /a D:(A;;GX;;;LS)
I haven't run sipsorcery on Mono/Linux myself now for many years so I'm not aware of what the equivalent of the httpcfg command would be.

wildsip
Posts: 23
Joined: Sun Jun 19, 2011 2:42 am

Re: Provisioning Service error for version 1.2 on mono

Post by wildsip » Sun Jun 19, 2011 11:08 pm

I got the provisioning service successfully started, by using wshttpbinding for the provisioning service instead of basichttpbinding. Not sure if this affects the application though.........

The other error I get is during registration of a provider

System Net Sockets SocketException in SIPUDPChannel Send Invalid Arguments
Exception SIPProxyCore GotRequest Invalid Arguments

What is this refering to ?

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Provisioning Service error for version 1.2 on mono

Post by Aaron » Mon Jun 20, 2011 3:06 am

Silverlight clients can only use basic http bindings so the provisioning service will not be usable with a ws binding.

I don't know what the reason for the exception on the UDP channel could be. It must be something different between Windows and Mono. What was occurring at the time of the exception? Was a request being sent or received?

wildsip
Posts: 23
Joined: Sun Jun 19, 2011 2:42 am

Re: Provisioning Service error for version 1.2 on mono

Post by wildsip » Mon Jun 27, 2011 3:22 am

The socket exception occurs in the proxyscript.py during registration of a provider at the line

sys.SendTransparent(destRegistrar, req, branch, publicip).

I checked the 4 values destRegistrar, req, branch and public ip with ToString methods and they look ok. Can an alternate Send method be used ?

if sipMethod == "REGISTER":
if remoteEndPoint.ToString() == m_regAgentSocket:
# A couple of registrars get confused with multiple Via headers in a REGISTER request.
# To get around that use the branch from the reg agent as the branch in a request that only has one Via.
branch = req.Header.Vias.PopTopViaHeader().Branch

# The registration agent has indicated where it wants the REGISTER request sent to by adding a Route header.
# Remove the header in case it confuses the SIP Registrar the REGISTER is being sent to.
destRegistrar = req.Header.Routes.PopRoute().ToSIPEndPoint()
req.Header.Routes = None
#sys.Log("destRegistrar " + destRegistrar.ToString() + "req " + req.ToString() + "branch " + branch.ToString() + "publi$
sys.SendTransparent(destRegistrar, req, branch, publicip)

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Provisioning Service error for version 1.2 on mono

Post by Aaron » Mon Jun 27, 2011 11:11 am

That block of code in the proxy script needs to do a few tricks to cope with SIP providers that only accept single Via headers and that don't like Route headers in REGISTER requests. You'll probably be safe enough without those tricks as it's only a small number of providers that require them. Try replacing the block with:

Code: Select all

 if sipMethod == "REGISTER":
    if remoteEndPoint.ToString() == m_regAgentSocket:
      dest = sys.Resolve(req)
      sys.Send(dest.ToString(), req, proxyBranch, localEndPoint.ToString())

    else:
      req.Header.ProxyReceivedOn = localEndPoint.ToString()
      req.Header.ProxyReceivedFrom = remoteEndPoint.ToString()
      sys.Send(m_registrarSocket, req, proxyBranch, m_proxySocketForRegisters)
It would take a bit of effort for me to set up the v1.2 sipsorcery version on my machine so I haven't tested the above snippet. Let me know how it goes.

wildsip
Posts: 23
Joined: Sun Jun 19, 2011 2:42 am

Re: Provisioning Service error for version 1.2 on mono

Post by wildsip » Tue Jun 28, 2011 4:38 am

I wrote a simple C# program that sent a UDP message (using System.Net.Sockets.UDPClient) from a source endpoint to a destination endpoint. Then I ran this program on windows and mono debian. What I found is that:

1. On windows sending a udp packet from 127.0.0.1:srcport to a non-private-ip:destport works fine with no exceptions.
2. Doing the same thing on mono debian, throws a System.Net.SocketException Invalid Arguments. If I use the private IP interface instead of the loopback address, mono does not have any issues and works fine.

3. Extending this to sipsorcery, I changed the sipsockets in sipsorcery-appsvr.exe.config for sipproxy, sipregistrar, sipregistrationagent and sipappserver and proxysrcipt.py to use the private IP of the server instead of the loopback address. Now I don't get the exception and providers are being registered and also sip clients are being registered by sipregistrar.

4. I do have exception for 2 items, do these affect SS operation ? . These occur in Windows also.

Exception SIPProxyDispatcher StartService. The ServiceHost must have at least one application endpoint (that does not include metadata exchange contract) defined by either configuration, behaviors or call to AddServiceEndpoint methods.

Exception starting internal notifications TCP hosted service. The ServiceHost must have at least one application endpoint (that does not include metadata exchange contract) defined by either configuration, behaviors or call to AddServiceEndpoint methods.

5. I am hoping on getting SS working on a NAS device running debian for ARM :)

Aaron, thanks for your responses.

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Provisioning Service error for version 1.2 on mono

Post by Aaron » Tue Jun 28, 2011 9:45 am

The two exceptions are related to the WCF (web service) end points that the sipsorcery application server is attempting to listen for requests on. None of the WCF end points are required for the sipsorcery application server to function properly as far as its SIP features go. The end points are for clients to connect to the application server to either perform provisioning operations or to receive notifications. You could get away without the former by updating your database or XML files directly. For the latter you can use the SSH console to receive notifications instead.

I'm very interested to hear how you go with running sipsorcery on Linux and on an ARM processor. Please keep this thread updated when you can.

wildsip
Posts: 23
Joined: Sun Jun 19, 2011 2:42 am

Re: Provisioning Service error for version 1.2 on mono

Post by wildsip » Sat Jul 02, 2011 5:38 pm

Has the sys.GoogleVoiceCall routine changed since version 1.2 ? It is ringing and says

Logging into google.com for xxx@gmail.com

but nothing happens after that and after canceling the call, it shows

Exception GoogleVoiceCall Login. Thread was being aborted


Also Is there a pure ruby or python script to do the googlevoice call without calling sys.GoogleVoiceCall ?

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Provisioning Service error for version 1.2 on mono

Post by Aaron » Sun Jul 03, 2011 12:37 am

There have been a few tweaks to the GoogleVoiceCall routine since v1.2. Mainly to do with cancelling calls and nothing that should stop you being able to initiate a call. The GoogleVoiceCall logic is largely de-coupled from the rest of the sipsorcery code so you should be able to get the latest version from http://sipsorcery.codeplex.com/SourceCo ... 551#476744 compiling with the v1.2 code base if you are building it.

The exception error message is normal. If a dialplan instance is terminated, for instance when the caller cancels the call, then there is no clean way to stop a running Ruby script and a thread abort is necessary.

There is no IronRuby script to initiate a Google Voice call and it's not possible to write one as IronRuby does not yet have support for SSL (which is a major pain). It probably would be possible to do an IronPython script but since I haven't wired up support for IronPython scripts in the sipsorcery dialplan engine you wouldn't be able to use it.

Post Reply