Trunk sip not receiving external call

[engineirie]

Hi everyone

I have an asterisk server that I’ve set with a SIP trunk. I can properly initiate external and internal call… but I am unable to receive external call.

I’ve tried to activate "pjsip set logger on » in the console so I can see the logs… but nothing is displayed concerning a incoming call.
The SIP provider can see the missing call through their interface but they ask me to pay them 150€/ hour to help me fix it (they say that the problem is on my side)

What I don’t understand is that when I use Wireshark I see an unauthorized request on a sip equipment but I cannot manage that equipment.

Is unauthorized related to an authentication issue on their equipment ?
Is it me that mistaken my pjsip.conf ?

(Attachment captureAppelEntrant.pcapng is missing)

[jcolp]

If you type “pjsip set logger on” and don’t see any SIP request, that means it never got to Asterisk or PJSIP is not listening. Do you have chan_sip loaded? It will listen on port 5060 by default and try to handle SIP traffic.

[engineirie]

I actually used : module show like chan_sip and it say 0 modules loaded.
I think sip is already inactive.
I added an attachment to the mail that can’t appear on the post.
It was showing the result of my wireshark analysis.
I’m gonna try to put it again.

[jcolp]

If traffic appears in a packet capture but not in Asterisk then that narrows it to:

1. A transport is not configured in pjsip.conf for listening on the IP address/port
2. The firewall is blocking the traffic, as a packet capture occurs BEFORE firewall

[engineirie]

Here is my pjsip.conf :
I activated transport-udp on port 5060 as the provider told me to . Is there something I missed ?

; Basic UDP transport
;
[transport-udp]
type=transport
protocol=udp ;udp,tcp,tls,ws,wss,flow
bind=0.0.0.0:5060
local_net=192.168.17.248/29
local_net=192.255.255.248/29
local_net=10.10.10.248/29
external_media_address=46.4.42.59
external_signaling_address=46.4.42.59


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;Définition des templates
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


[user_registration](!)
type=registration
server_uri=sip:192.255.255.251
transport=transport-udp

[assistance_endpoint](!)
type=endpoint
transport=transport-udp
context=assistance
disallow=all
allow=ulaw,alaw,g722,gsm
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
identify_by=auth_username

[assistance_auth](!)
type=auth
auth_type=userpass

[assistance_aor](!)
type=aor
max_contacts=1
remove_existing=yes

[commercial_endpoint](!)
type=endpoint
transport=transport-udp
context=commercial
disallow=all
allow=ulaw,alaw,g722,gsm
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
identify_by=auth_username

[commercial_auth](!)
type=auth
auth_type=userpass

[commercial_aor](!)
type=aor
max_contacts=1
remove_existing=yes


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;Définition des endpoints
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


[vromain](assistance_endpoint)
auth=vromain_auth
aors=vromain

[vromain_auth](assistance_auth)
username=vromain
password=test

[vromain](assistance_aor)


[jandrena](assistance_endpoint)
auth=jandrena_auth
aors=jandrena

[jandrena_auth](assistance_auth)
username=jandrena
password=test

[jandrena](assistance_aor)



[commercial](commercial_endpoint)
auth=commercial_auth
aors=commercial

[commercial_auth](commercial_auth)
username=commercial
password=test

[commercial](assistance_aor)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;Définition du trunk sip sur le numéro SDA +594595140950
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[+594594140950]
type=endpoint
transport=transport-udp
context=+594594140950
disallow=all
allow=ulaw,alaw,g722,gsm
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
identify_by=auth_username
aors=+594594140950
outbound_auth=+594594140950_auth
auth=
;outbound_auth=+594594140950_outbound_auth
outbound_proxy=sip:sip.telcoz.eu
callerid=+594594140950 +594594140950

[+594594140950_auth]
type=auth
auth_type=userpass
username=engineirie97300
password=*********************
realm=sip.telcoz.eu
nonce_lifetime=3600

[+594594140950_local_auth]
type=auth
auth_type=userpass
username=+594594140950
password=test
realm=192.255.255.251
nonce_lifetime=3600

[+594594140950_outbound_auth]
type=outbound_auth
username=engineirie97300
password=*********************
realm=sip.telcoz.eu

[+594594140950_proxy]
type=outbound-proxy
proxy=sip:sip.telcoz.eu
transport=transport-udp
send_dns_srv=yes

[+594594140950]
type=aor
max_contacts=1
remove_existing=yes
contact=sip:engineirie97300@sip.telcoz.eu

[+594594140950_registration]
type=registration
server_uri=sip:sip.telcoz.eu
client_uri=sip:engineirie97300@sip.telcoz.eu
contact_user=+594594140950
transport=transport-udp
outbound_auth=+594594140950_auth

;[+594594140950]
;type=identify
;endpoint=+594594140950
;match=sip.telcoz.eu

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;

[jcolp]

That should cause it to listen on port 5060, which would seem to indicate that it is perhaps a firewall outside of Asterisk blocking it if you truly do not see SIP traffic with “pjsip set logger on” done.

[engineirie]

I’ll check that again but i see no logs blocked by my pfsense coming from the address correspondig to sip2sip.info for example.

I also authorized 5060 an d5061 in every location of my network.

[david551]

@engineirie

[+594594140950]
type=endpoint
transport=transport-udp
context=+594594140950
disallow=all
allow=ulaw,alaw,g722,gsm
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
identify_by=auth_username

This isn’t going to work for any normal provider. I guess the identify may cause you to send 401, but you have nothing to authenticate against, and provider is likely to assume that to be the case, and not even try to authenticate.

Even when somewhat meaningful, identify by authuser is inadvisable.

@engineirie

nonce_lifetime=3600

I rather doubt that this is used with outbound authentication, but when used, I’d say it was opening you up to a replay attack.

[engineirie]

@david551

This isn’t going to work for any normal provider. I guess the identify may cause you to send 401, but you have nothing to authenticate against, and provider is likely to assume that to be the case, and not even try to authenticate.

Even when somewhat meaningful, identify by authuser is inadvisable.

Do you lmean that I should delete the “indentify_by” options ?
How should I edit it ?

The provider told me to use a login/password authentication type. I thaugtht that would be the correct way to set it.

Also i’m going to delete the nonce_lifetime option

[tootai]

try, from asterisk server,

dh@feijoa [~] $ nc -vu 213.186.33.5 5060
Connection to 213.186.33.5 5060 port [udp/sip] succeeded!

if you don’t get the “succeeded” there is a FW problem

[engineirie]

Thank you for this advice.
I can now confirm that it suceed :

~$ sudo nc -vu 213.186.33.5 5060
[sudo] password for vromain:
Connection to 213.186.33.5 5060 port [udp/sip] succeeded!

[engineirie]

What do you ùean by I have nothing to authenticate against ?

I noticed that I always have a few unauthorized register request before it reach to register.

It always try by sending no credentials and then it try to use the credentials taht I provided from the beginning…

[david551]

I’m saying you need to change something. Normally providers would be identified by IP address.

[engineirie]

I asked the provider to give some details but they’re only saying that they respect the MAN legislation and e.164 norms…
I asked if the calls identification are based on ip, username… And I wait their answer…

The operator knows 3CX and freePBX but doesn’t know asterisk itself and cannot help.
They’ll only answer if I pay 150€/h of support with an engineer…

I tried to set identify_by=ip.
Currently I have no difference.
Do you know why the call can go through the trunk from my pbx to the wan but not from the wan to my pbx ? Isn’t it already registered and identified ?

[engineirie]

Do I need to to have an auth section for local registration and an outbound-auth section for the trunk ?

[david551]

The identify by for the provider is how you identify calls from the provider. It has nothing to do with how the provider identifies calls from you

[engineirie]

But how do they identify the caller that want to contact me ?

[tootai]

MAN is STIR/SHAKEN which officially goes started in France as of 01/10/2024

Question: did you request certificats with FFT and implement Stir/Shaken is asterisk or is your provider taking care of your certificats and does the job for you?

[engineirie]

Do you mean that i should have a certificate delivered by the provider to allow me to receive the calls ?
Do I need to set it on my asterisk server ?

[tootai]

Not from the provider. Are you registered at ARCEP and FFT (Federation Francaise des Telecom)? If yes, you have to deal with them to get certificats and sign your calls for your numbers. If you’re not, the provider from where you have your numbers should do it for you.

That’s what we do for our customers in France.