603 when recieving call from a peer IP

Hey I have an issue with calls coming coming from an IP address that is a peer/friend. I am getting a fast busy 603 where I am expecting a 401. I have confirmed that the problem lies with the peer/friend IP existing in the sip.conf file as I am getting the expected bahavior if I remove this peer.
How can I get asterisk to work both ways? ie use the peer for Asterisk outbound but also to recieve inbound calls from that IP to follow the dial plan.
Diagram below

  1. Cloud PABX calls external freeswitch interface.
  2. FS bridges call to asterisk on 1.1.1.2
  3. Asterisk rejects with 603 (because 1.1.1.1 is in sip.conf)
  4. If 3cx calls outbound it works fine

Without the logs and actual configuration, the only thing one can really say is: why are you using an obsolescent channel driver, rather than chan_pjsip?

I would note that most uses of friend should be peer, even for local phones.

Hey David,
I am using channel as we have multiple routing servers with A2Billing and no time nor reason to change something that works just fine. Also I am new to asterisk so this could certainly be a silly question.
I guess what I should have asked is that given I cannot change this source IP address (1.1.1.1) I need to some differentiate that calls coming from ITSP are to go to a different context in SIP.conf compared to calls that come from Cloud PABX.
ATM we are matching [FS] based on 1.1.1.1 so all calls are going to the Billing-DID context which is looking up the DID table built into A2Billing.
I need Cloud PABX calls with source IP 1.1.1.1 to go to a different context, what can I add to SIP.conf to diferentiate the 2 calls.
In freeswitch I can manipulate things like the from-domain, port, customer headers etc

1/ create a context in extensions.conf to do the routing that you wish
2/ change context in sip.conf for the peer to the context you just created in step1
3 / read the Asterisk handbook, it only takes a few hours
4 / start thinking abt upgrades, both chan_sip and a2billing are obsolete

Hey khlam,
yes but the source/host IPs are the same so how can i have sip.conf send a call from host 1.1.1.1 to a different peer ie [FS] or [FS2] or even nocontext
based on some different from-domain (for example) something like the below
(i say no context because if the peer is not in sip.conf then it dials out a2billing-odbc and works as expected)

domain=3rdpartypabx.com,[FS2]

sip-custom.conf
[FS1]
type=peer
host=1.1.1.1
dtmfmode=rfc2833
directmedia=yes
disallow=all
allow=alaw
insecure=port,invite
nat=force_rport,comedia
context=Billing-DID
match_auth_username=no

[FS2]
type=peer
host=1.1.1.1
dtmfmode=rfc2833
directmedia=yes
disallow=all
allow=alaw
insecure=port,invite
nat=force_rport,comedia
;context=Billing-DID
match_auth_username=no

That will tell you how you can examine the headers in the request and redirect the call to a more appropriate context.

Hey David,

can you please link me to the ‘Asterisk handbook’
Is it this - https://docs.huihoo.com/asterisk/handbook-draft.pdf
or
http://asterisk-service.com/downloads/Asterisk-%20The%20Definitive%20Guide,%204th%20Edition.pdf

I am still struggling to get it to go and have had a look at the sample files. I have tried ‘fromdomain’ option in sip.conf again is for setting the outbound fromdomain
domain option in sip.conf is for a registration domain not a lookup against an inbound INVITE header
I cant use 2x different ports as asterisk only binds to 1x IP

because the source host is always 1.1.1.1, its always going to go to context Billing-DID…but I need to get some calls some how to go to a different context. Can the extensions.conf lookup the fromdomain and move the call to a different context inside the dialplan?

The primary documentation sources for Asterisk are Asterisk the Definitive Guide, and the wiki. Even the printed version of the guide is a bit dated, but there shouldn’t be any material differences for what you need to do. Older versions are available online, and should also be good enough.

The wiki is:

https://wiki.asterisk.org/wiki/display/AST/Home

You should be looking at extensions.conf, not (pj)sip.conf, and in particular you should be looking at functions for accessing headers, condition handling, and GotoIf.

ok thanks, going through these now. So please riddle me this, in sip.conf we will just send all the calls to
[Billing-DID]

in extensions.conf we can then go
[Billing-DID]
exten => _X.
if sip-from-header=cloudpabx.com
goto a2billing-odbc
elif
continue to A2Billing inbound DID Database

[a2billing-odbc]
exten => _X.
lookup trunk info in database
challenge auth
dial out

Hey Guys,
I am close but stuck on
IF This = true, move context (works)
Else Continue in this context (doesnt work)

[from-routing]
exten => 123456,1,Set(SIP_INVITE_DOMAIN=${CUT(CUT(SIP_HEADER(From),>,1),@,2)})
same => n,NoOP(FROM HOST IS ${SIP_INVITE_DOMAIN})
same => n,GotoIf($["${SIP_INVITE_DOMAIN}" != “3rdpartypabx.com”]?Goto(continue)
same => n,ExecIf($["${SIP_INVITE_DOMAIN}"=“3rdpartypabx.com”]?Goto(domain-bypass,123456,1))
same => n(continue),NoOp(Continue in this context as from domain is not ${SIP_INVITE_DOMAIN})
same => n,123456,1,Dial(SIP/799998,30)
same => n,123456,n,Hangup()

[domain-bypass]
exten => 123456,1,Dial(SIP/799999,30)
exten => 123456,n,Hangup()

You are mixing up GotoIf and ExecIf.

There are bogus characters (123456,1 and 123456,n) in your last two lines of your initial context.

It would be better to use ${EXTEN}, rather than 123456 in the Goto.

You may need touse a pattern, rather than 123456 in the exten => lines.

Hey,
Yes I do have this working now. It probably still needs some tidy up but its doing what I want it to do which is to move from one context to the next based on the SIP FROM header
The problem is, it did not solve my problem :frowning: When the call moves from one context to the next it is still returning a 603 instead of a 401 to retrieve credentials.

Can I do something in the dial plan below to kick off a 401 to retrieve credentials

[Billing-DID]
;used for inbound
exten => _X.,1,NoOp(“Dest: ${EXTEN}”)
same => n,Set(SIP_INVITE_DOMAIN=${CUT(CUT(SIP_HEADER(From),>,1),@,2)})
same => n,NoOP(FROM HOST IS ${SIP_INVITE_DOMAIN})
same => n,GotoIf($["${SIP_INVITE_DOMAIN}"!=“3rdpartypabx.com”]?continue)
same => n,ExecIf($["${SIP_INVITE_DOMAIN}"=“3rdpartypabx.com”]?Goto(a2billing-odbc,${EXTEN},1))
same => n(continue),NoOp(Continue in this context as from domain is not ${SIP_INVITE_DOMAIN})
same => n,NoOp(Call Coming from ${CALLERID(all)} to ${CDR(accountcode)} with extension start with first number ${EXTEN:0:1})
etc etc
Dial

[a2billing-odbc]
;used for outbound
to long to post but this works if I remove the peer with IP Address 1.1.1.1 from sip.conf

fail moving context
Executing [0400123456@Billing-DID:1] NoOp(“SIP/FS-00000000”, "“Dest: [0400123456"”) in new stack
Goto (a2billing-odbc,0400123456,1)
– Executing [0400123456@a2billing-odbc:62] Hangup(“SIP/FS-00000000”, “57”) in new stack

working with 1.1.1.1 removed
– Executing [0400123456@a2billing-odbc:40] Dial(“SIP/5742324772-00005816”, “SIP/0400123456@SBC1,60,iL(7200000:61000:30000)”) in new stack

Authentication has to be done in sip.conf.

I think I ignored the 603 because I didn’t understand the situation, and concentrated on the more specific question of distinguishing different streams from the same peer.

I don’t understand why you cannot authenticate 1.1.1.1. I get the impressions that there is something very weird in your network. Is 1.1.1.1 acting as a proxy, rather than a switch?

1.1.1.1 is freeswitch which is acting as a B2BUA. I am just bridging inbound calls from the 3rd party cloud PABX towards A2Billing Asterisk 1.1.1.2

Below is its SIP.conf entry. I have already tried commenting out ;insecure=port,invite

[FS]
type=friend
host=1.1.1.1
dtmfmode=rfc2833
directmedia=yes
disallow=all
allow=alaw
insecure=port,invite
nat=force_rport,comedia
context=Billing-DID
match_auth_username=no

I guess a solution could be to change it to the below?
[FS]
host=dynamic
username=111111111
secret=2222222
context=Billing-DID

And on the freeswitch (1.1.1.1) on the calls that come from the ITSP carrier, bridge those calls to 1.1.1.2 using the credentials 111111 and 22222
ie
<action application="bridge" data="{sip_auth_username=1111111,sip_auth_password=2222222}sofia/internal/$1@1.1.1.1"/>

this way calls coming from 3rd party PABX will not match anything in SIP.conf and therefore be challenged with 401

insecure=invite does nothing, because you have no secret. It actually stops a 401 being sent, but not having a secret also stops a 401 being sent.

Please explain why you have the following settings:

type=friend (rather than peer)
insecure=port (is FreeSwitch not consistently using port 5060?)
nat=comedia (you didn’t mention any NAT between you and FreeSwitch, and this option is only for when the peer is inside NAT and Asterisk is outside that NAT - in most cases Asterisk will discover that for itself and automatically apply this, if you leave things as default)
nat=force_rport (as the previous one)
match_auth_username (I’ve never really worked out where this is useful, because you generally need to recognize the peer before you send it the 401 to request the authentication, but you are never going to request authentication if you have no secret to check).

My best guess is that it is the match_auth_username that is causing the problem, as no Authorization header will ever be sent, as there is no secret to check. This is probably resulting in no match at all. Other possibilities are that the from user is spoofing a local device that is also wrongly configured as a friend, or that FreeSwitch is confusing things by sending a password when none is configured (although that seems unlikely).

oh ok got it thanks.
TBH, I have inherited this system recently and have been tasked to get outbound working on the 3rd party PABX. The current settings could very well be un-optimal so in dont have an explanation as to why it is setup this way.
Freeswitch is not sending a credential as it gets back a fast 603.
It may be set to friend as this may be a ‘A2Billing’ requirement to capture CDR for inbound and outbound calls but I can certainly try setting it to peer to see what happens.

I can try the below however I still think I will have the same issue with no challenge before moving context based on SIP FROM domain.

[FS]
type=peer
host=1.1.1.1
dtmfmode=rfc2833
directmedia=yes
disallow=all
allow=alaw
nat=no
context=Billing-DID

I am thinking I may need to remove the host= componant and go something like the below.

  1. Inbound calls to 1.1.1.2 are linked to the context via the credentials and not the IP
  2. Outbound calls will use this SIP user and dial out freeswitch 1.1.1.1 with no credentials
[FS]
type=user
host=dynamic
outboundproxy=1.1.1.1
username=1111111
secret=2222222
dtmfmode=rfc2833
directmedia=yes
disallow=all
allow=alaw
nat=no
context=Billing-DID

Please let me know if I am still off the mark.

Don’t use nat=no. The default of auto-comedia, auto-force-rport works in most cases.

sigh, I have tried to get inbound to 1.1.1.2 from 1.1.1.1 with credentials instead of a matching peer IP, but with the below in sip.conf I send an invite and get a 401 followed by a 403 unauthorised even though the credentials are correct.

[FS]
type=friend or user
host=dynamic
outboundproxy=1.1.1.1
;authuser=1234 or ;
username=1234
secret=1234
dtmfmode=rfc2833
directmedia=yes
disallow=all
allow=alaw
nat=force_rport,comedia
context=Billing-DID
match_auth_username=yes or no

Why are you specifying an outbound proxy?

i have also tried ; that out
The idea was in A2Billing to setup a trunk to use [FS] to dial outbound towards the ITSP.
If I was going to use a user of a friend it would need to go via freeswitch 1.1.1.1

chan_sip.c:26179 handle_request_invite: Failed to authenticate device "0400123456" <sip:0400123456@1.1.1.1>;tag=71Ha332QpS84B