Asterisk not respond to invite from a provider

[nghianv]

Hi, recently I bought a hotline from a Gtel provider in my country.
As usual I create a trunk with pjsip. When I make outgoing calls, no problem.
But for incoming calls, asterisk does not respond to Gtel’s request.
sngrep shows that G keeps sending invite multiple times.

This is my setup:
Asterisk 20.2.1 (tried 18.10 too, no luck)
Ubuntu server 20.04
84123456789 is the caller_id that Gtel gave me, i created endpoint 0123456789 to match that caller_id.

1.1.1.1 is Gtel’s ip
2.2.2.2 is my ip, 5.5.5.5 is another interface on this server
3.3.3.3 and 4.4.4.4 my other provider FPT’s ip

The attached file contain the log form asterisk with logger on 1.1.1.1 and debug level 6
asterisk_not_responed_to_invites.txt (32.5 KB).

this is the config for this trunk, read from asterisk cli:
pjsip show endpoint 0123456789

 100rel                             : yes
 accept_multiple_sdp_answers        : false
 accountcode                        :
 acl                                :
 aggregate_mwi                      : true
 allow                              : (alaw)
 allow_overlap                      : true
 allow_subscribe                    : true
 allow_transfer                     : true
 allow_unauthenticated_options      : false
 aors                               : 0123456789
 asymmetric_rtp_codec               : false
 auth                               :
 bind_rtp_to_media_address          : false
 bundle                             : false
 call_group                         :
 callerid                           : <unknown>
 callerid_privacy                   : allowed_not_screened
 callerid_tag                       :
 codec_prefs_incoming_answer        : prefer:pending, operation:intersect, keep:all, transcode:allow
 codec_prefs_incoming_offer         : prefer:pending, operation:intersect, keep:all, transcode:allow
 codec_prefs_outgoing_answer        : prefer:pending, operation:intersect, keep:all, transcode:allow
 codec_prefs_outgoing_offer         : prefer:pending, operation:union, keep:all, transcode:allow
 connected_line_method              : invite
 contact_acl                        :
 context                            : default
 cos_audio                          : 0
 cos_video                          : 0
 device_state_busy_at               : 0
 direct_media                       : false
 direct_media_glare_mitigation      : none
 direct_media_method                : invite
 disable_direct_media_on_nat        : false
 dtls_auto_generate_cert            : No
 dtls_ca_file                       :
 dtls_ca_path                       :
 dtls_cert_file                     :
 dtls_cipher                        :
 dtls_fingerprint                   : SHA-256
 dtls_private_key                   :
 dtls_rekey                         : 0
 dtls_setup                         : active
 dtls_verify                        : No
 dtmf_mode                          : auto
 fax_detect                         : false
 fax_detect_timeout                 : 0
 follow_early_media_fork            : true
 force_avp                          : false
 force_rport                        : false
 from_domain                        : 2.2.2.2
 from_user                          : 842499995446
 g726_non_standard                  : false
 geoloc_incoming_call_profile       :
 geoloc_outgoing_call_profile       :
 ice_support                        : false
 identify_by                        : username,ip
 ignore_183_without_sdp             : false
 inband_progress                    : false
 incoming_call_offer_pref           : local
 incoming_mwi_mailbox               :
 language                           :
 mailboxes                          :
 max_audio_streams                  : 1
 max_video_streams                  : 1
 media_address                      :
 media_encryption                   : no
 media_encryption_optimistic        : false
 media_use_received_transport       : false
 message_context                    :
 moh_passthrough                    : false
 moh_suggest                        : default
 mwi_from_user                      :
 mwi_subscribe_replaces_unsolicited : no
 named_call_group                   :
 named_pickup_group                 :
 notify_early_inuse_ringing         : false
 one_touch_recording                : false
 outbound_auth                      : 0123456789
 outbound_proxy                     :
 outgoing_call_offer_pref           : remote_merge
 overlap_context                    :
 pickup_group                       :
 preferred_codec_only               : false
 record_off_feature                 : automixmon
 record_on_feature                  : automixmon
 refer_blind_progress               : true
 rewrite_contact                    : false
 rpid_immediate                     : false
 rtcp_mux                           : true
 rtp_engine                         : asterisk
 rtp_ipv6                           : false
 rtp_keepalive                      : 0
 rtp_symmetric                      : false
 rtp_timeout                        : 30
 rtp_timeout_hold                   : 0
 sdp_owner                          : asterisk
 sdp_session                        : asterisk
 send_aoc                           : false
 send_connected_line                : yes
 send_diversion                     : false
 send_history_info                  : false
 send_pai                           : false
 send_rpid                          : false
 set_var                            :
 srtp_tag_32                        : false
 stir_shaken                        : off
 stir_shaken_profile                :
 sub_min_expiry                     : 0
 subscribe_context                  :
 suppress_q850_reason_headers       : false
 t38_bind_udptl_to_media_address    : false
 t38_udptl                          : false
 t38_udptl_ec                       : none
 t38_udptl_ipv6                     : false
 t38_udptl_maxdatagram              : 0
 t38_udptl_nat                      : false
 timers                             : yes
 timers_min_se                      : 900
 timers_sess_expires                : 1800
 tone_zone                          :
 tos_audio                          : 0
 tos_video                          : 0
 transport                          : transport-udp
 trust_connected_line               : yes
 trust_id_inbound                   : false
 trust_id_outbound                  : false
 use_avpf                           : false
 use_ptime                          : false
 user_eq_phone                      : false
 voicemail_extension                :
 webrtc                             : no

pjsip show aor 0123456789

 authenticate_qualify : false
 contact              : sip:0123456789@1.1.1.1:5060
 default_expiration   : 3600
 mailboxes            :
 max_contacts         : 0
 maximum_expiration   : 7200
 minimum_expiration   : 60
 outbound_proxy       :
 qualify_frequency    : 10
 qualify_timeout      : 3.000000
 remove_existing      : false
 remove_unavailable   : false
 support_path         : false
 voicemail_extension  :

pjsip show identify 0123456789

 endpoint      : 0123456789
 match         : 1.1.1.1/255.255.255.255
 match_header  :
 srv_lookups   : true

pjsip show transport transport-udp

 allow_reload               : false
 allow_wildcard_certs       : No
 async_operations           : 1
 bind                       : 2.2.2.2:5060
 ca_list_file               :
 ca_list_path               :
 cert_file                  :
 cipher                     :
 cos                        : 0
 domain                     :
 external_media_address     :
 external_signaling_address :
 external_signaling_port    : 0
 local_net                  :
 method                     : unspecified
 password                   :
 priv_key_file              :
 protocol                   : udp
 require_client_cert        : No
 symmetric_transport        : false
 tos                        : 0
 verify_client              : No
 verify_server              : No
 websocket_write_timeout    : 100

Seems like asterisk was sending 100 to Gtel but something happened and stopped the process.
Please help!

[jcolp]

You haven’t shown the actual endpoint and transport configuration. You also generally match on IP address and not callerid, but that’s up to you.

[david551]

@nghianv

84123456789 is the caller_id that G gave me, i created endpoint 0123456789 to match that caller_id.

The caller ID in your example is not that, it is 0934569616. Matching the To header is just about possible, although I’m not sure if Asterisk Realtime supports it, as I’ve never used that. Why are you using ARA for providers? In any case, matching in the To headers seem pointless and a possible security risk.

From my point of view, the logging is too detailed, you should set debug=0 and verbose=3, and include at least two INVITE requests.

@nghianv

from a G provider in my country.

This confused me on the first few readings. I think it actually means “from a provider, which I will call G, in my country”. However, I would not that obscuring the identity of a provider makes providing help difficult and doesn’t seem to have any security advantage.

[nghianv]

I’ve added some config read from asterisk cli, please have a look!

[jcolp]

Where is the transport being configured?

[nghianv]

the 0934569616 is the caller number, my sim number. I’ve made a call to 0123456789 to receive the invite from Gtel.

caller id is what my provider called 0123456789.

I’ve built a system which can help me setup a trunk with a few clicks on a webpage, and ARA is so easy to use for me.

If I set debug=0, cli will only show some invite requests, nothing else.

I will “reveal” the real names of those providers

[nghianv]

In pjsip.conf, here’s its content.

[global]
type=global
mwi_disable_initial_unsolicited=yes

[transport-udp]
type=transport
protocol=udp
bind=2.2.2.2

[jcolp]

All I can say is that we asked PJSIP to create a 100 Trying as the initial answer and it refused to do so. Why that is, I don’t know.

[rlockard]

I can confirm that matching the To header in Asterisk Realtime is supported and works as expected to split incoming calls from same provider to different endpoints on the system. I use it in combination with the IP address match, mainly for a multi-tenancy type situation. Using this with ARI, I can direct each separate customer incoming calls to their own ARI app without needing any dialplan on the Asterisk servers since ARI now creates its own context dynamically. Without using it, the matching was unpredictable of course, with multiple endpoints having the same IP addresses to match.

It has its purpose, but like you say, it isn’t needed here. I DO NOT use Realtime Extensions, which has known performance issues, but is what the OP is attempting to do.

[david551]

@nghianv

and ARA is so easy to use for me.

The problem with ARA is that is not so well supported (in some cases only community support) as config files, and that it is difficult to debug compared with well written config files, in that you get huge numbers of parameters, most of which are actually defaults or irrelevant, but you have to trawl them all to look for anything strange.

There are also issues with lazy evaluation, done for performance, which means that diagnostics may not show current values.

And, typically provider settings are the most complex ones, but there are very few in any one system.

[david551]

When the OP provided their actual configuration, it turned out they were actually matching on IP address, not To or From.