Outgoing call authentication / routing

Discussions about using SIP Sorcery on your own computer/server
Post Reply
StephenWRogers
Posts: 4
Joined: Sat Mar 06, 2010 8:03 pm

Outgoing call authentication / routing

Post by StephenWRogers » Mon Mar 08, 2010 4:22 pm

Hi

I've installed the lcoal version and am playing around with it in order to use it to route outgoing calls in a particular way.

I've currently got a Cisco router that registers with Sipgate, but as the router can only register one authentication request all the outgoing calls route through this number. I am trying to put a local copy of SipSorcery in the middle in order to route calls to the relevant sipgate account based on the phone that makes the call.

I've installed the app and set up 2 providers to sipgate, which register successfully. I've also set up a new account ( say called aaa) and bound my Cisco router to SipSorcery using this account.

Now when I make a call and the calling number - the Header.From.FromURI.User I guess - is not "aaa", say "bbb" I get an error saying "bbb" is not a valid account.

Fair enough, but then if I set up a sub-account under the main "aaa" account called "bbb" and try again I get hit with a "Authentication token check failed" from within the SIPRequestAuthenticator.AuthenticateSIPRequest call.

I can make a small change to the code to manually set the Owner and SIPUsername properties of sipAccount (at about line 94) to "aaa" to make the authentication check pass, and indeed when I do this the call is subsequently routed through the dial plan for "bbb" successfully.

Is there a better way to do this? I'd like the From User to be used to select the dial plan from that sub account without having to insert some code to make the Authentication token check pass. What's causing that check to fail?


Thanks

Stephen

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

Post by Aaron » Mon Mar 08, 2010 11:35 pm

Hi Stephen,

Is the authentication failure between a SIP client and the local version of sipsorcery or between sipsorcery and a SIP provider?

I suspect the latter in which case when you send the call to a 3rd party provider are specifying a provider name in the Dial command, e.g. sys.Dial("1234@myprovider"), or using a hostname, e.g. sys.Dial("1234@sip.myprovider.com")?

Regards,

Aaron

StephenWRogers
Posts: 4
Joined: Sat Mar 06, 2010 8:03 pm

Post by StephenWRogers » Tue Mar 09, 2010 9:10 am

It's an authentication failure between the client and a local version of sipsorcery.

The request's authentication header has User = "aaa" (as that's the user name I've bound the Cisco router to sipsorcery with), but the sipAccount that is in the From field of the request header is "bbb" - I'm trying to route calls depending on this field - ie who is calling.

The authentication failure then happens on line 110 of SIPRequestAuthentictor as essentially the sipAccount.SIPUsername ("aaa") != the reqAuthHeader.SIPDigest.Username ("bbb"), even though "bbb" is a valid sub-account of "aaa"



My issue is that I can only bind the router to sipsorcery with one username, but want to be able to make calls from multiple numbers and route them accordingly.

Thanks,

Stephen

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

Post by Aaron » Tue Mar 09, 2010 9:48 am

Hi Stephen,

Ok I understand the issue now.

It's policy driven as to how a server should react when the From URI user differs from the username in the digest. It wouldn't be hard to come up with a policy for sipsorcery but it would be such an infrequently used feature I don't think it would justify the effort.

Have you tried using IP address authentication for your local instance SIP accounts? If your Cisco router is on a static IP you could tell the sipsorcery server to authenticate based on IP address rather than on digest by using the ipaddressacl field.

Regards,

Aaron

Post Reply