Incoming/Outgoing calls matching the wrong SIP peers

Hi All,

I’ve been battling with this issue for some time and I would like to see if anyone has had a similar one.

Our setup is the following:

Asterisk header box as the registrar, handling all of the contexts and registration of remote phones etc:

Client side is either an asterisk box/sip phone

In between we have a Telcobridges SBC which handles all of the registration forwarding.

The process is as following, we register the user on sip-voipserver.example.co.za which resolves to the IP address of the SBC, this registration then gets forwarded to the asterisk header box. This is all working and everything registers. The problems comes in when we have multiple phones/systems registering to the same domain using this method coming from the same IP address of the SBC(since that is where the registration is being forwarded from).

What happens is that when a calls gets made by one of the phones/asterisk server, it somehow gets confused and presents the wrong did/callerid. It will use one of the existing users that is registered using the same method. So now we have a massive billing problem where clients are saying they didn’t make that many calls and their billing is wrong, which is correct because it is as a client is making a call on behalf of them.

If you have any ideas let me know. For the time being, we’ve created different interfaces on the SBC to register the users from, but this is very tedious and time consuming.

If outgoing calls aren’t matching, you need to look outside Asterisk.

Which SIP technology driver are you using (sip or pjsip).

What are expecting Asterisk and the SBC to use to disambiguate the IP address? (Note that SIP requests do not have any header which correlates them with a registration.

Details of your Asterisk configuration are likely to be useful.

Hi David,

We’re using SIP technology. This is an example of one of the SIP users:

; 1234
[1234]
dtmfmode=rfc2833
disallow=all
allow=g729
allow=alaw
type=friend
callerid=<1234>
accountcode=1234
defaultuser=1234
secret=1234
remotesecret=1234
host=dynamic
directmedia=no
insecure=invite,port
qualify = 5000
nat=force_rport,comedia
mailbox=1234@post-office
context=example

Context

[example-fromsbc]
exten => _12345678,1,NoOp(.call for .{EXTEN}) same => n,Set(CDR(userfield)=SIP In) same => n,Set(CALLEDEXTEN={EXTEN})
; same => n,Dial(SIP/${EXTEN},rtT)
same => n,Dial(SIP/12345678&SIP/1234567,rtT)
same => n,Hangup()

[example-tosbc]
exten => _XXXX.,1,NoOp(.call for .{EXTEN}) same => n,NoOp(Channel is {CHANNEL:0:14})
same => n,GotoIf(["{CHANNEL:0:14}" = “SIP/12345678”]?callout)
same => n,GotoIf(["{CHANNEL:0:14}" = “SIP/1234567”]?callout)
same => n,Hangup()
same => n(callout),Gosub(sub-call-setup-sbc,${EXTEN},1)
same => n,Hangup()

We map a domain i.e sip.proxy.com to our OPEN Nap interface on the SBC which purpose is to forward the registrations to the registrar which then executes the dialplan.

The SIP requests come from the same IP i.e 1.2.3.4 but the difference is the user and sip domain.

The combination of secret, remotesecret and insecure=invite does not make sense. Please read up what they actually do. This is basically equivalent to just specifying remotesecret.

insecure=port eliminates the main option for distinguishing the accounts.

Does the SBC send From: 1234@… If not type=friend confuses the issue, by not giving you anything but introducing possible false matches.

Based on the above nat= may be cut and paste coding, and unnecessary.

You don’t have any account in the context example-fromsbc, so nothing will hit that dialplan.

Your dialplan does not contain any code that makes an outgoing call, so there is no way of seeing how you try and identify to the SBC.

Which user and SIP domain differ? The only one that could be used to select a sip.conf entry is the From user. If only the request information differs, you have to treat them all as one peer and discriminate in the dialplan, or, just possibly see if removing insecure=port, and using type=peer helps, although a necessary condition for that would be that the SBC returns contact URIs with different port numbers, which it probably doens’t, and might not work.

Hi David,

I’ve done some reading and agree with you, having remotesecret and secret is redundant, I will ammend that. As you know, Asterisk can only run on one port at any time and if it just relies on matching the IP address and all of the remote registered users are coming from the same IP address I imagine this would be an issue? I can remove the NAT option as it is coming from a Non natted interface. I’ve changed it to peer as well.

Regarding the account context, there is a Gosub which refers to this dialplan which executes the dialing out:

[sub-call-setup-sbc]
exten => _X.,1,NoOp(.call for .{EXTEN}) same => n,NoOp(== Caller ID is {CALLERID(all)} ==)
same => n,Set(CDR(userfield)=SBC Trunk Out)
same => n,GosubIf(["{ENABLETHROTTLEAGI}"=“yes”]?sub-agi-throttle,{EXTEN},1({CDR(dst)},{SBCTRUNK})) same => n,Dial({SBCTRUNK}/{EXTEN},,r) same => n,Set(channeluniqueid={CDR(uniqueid)})
same => n,Set(channeluserfield={CDR(disposition)}-{DIALSTATUS}-{HANGUPCAUSE}) same => n,NoOp(== SBC Trunk {SBCTRUNK}: Call ended with {DIALSTATUS} ==) same => n,Gosub(sub-failed-calls,{EXTEN},1({channeluserfield},{channeluniqueid}))
same => n,Hangup()

Regarding the user and SIP domain differing. We have a extra SIP file to place all of these users. Only the Users differ, i.e each user’s name and secret is different but the sip domain is the same for everyone. I can check if the SBC can return URI’s with different port no’s and let you know.

pjsip can use more than one port at the Asterisk end.

I’m not sure if different remote ports can be used to match the remote end, or whether the Asterisk always rejects all but the one true port. Obviously that will only work if you turn off insecure=port.

Asterisk can match on the From user or the authentication user, but not if you have insecure=invite.