Problem With Pjsip

Home » Asterisk Users » Problem With Pjsip
Asterisk Users 1 Comment

Hello everyone. I allow myself to submit a problem that I can not solve with my VOIP
provider Orange in France

[2023-06-08 13:19:03] ERROR[185091]:
res_pjsip/pjsip_configuration.c:1044 from_user_handler: Error configuring endpoint ‘Biv_Sortie’ – ‘from_user’ field contains invalid character ‘@’
[2023-06-08 13:19:03] ERROR[185091]: config_options.c:798
aco_process_var: Error parsing from_user=75B55BTQUHSG@orange-obs.fr at line 0 of
  == chan_pjsip.so => (PJSIP Channel Driver)

1) Error with “@” character which constitutes URI and authuser see excerpt from pjsip.conf.

[transport-udp]
type = transport protocol=udp bind=0.0.0.0:5060
local_net=172.16.1.0/255.255.255.0

[reg_orange-obs.fr]
type = registration retry_interval = 120
max_retries = 10
expiration = 120
transport = transport-udp outbound_auth = auth_reg_orange-obs.fr client_uri = sip:+3313445XXXX@orange-obs.fr server_uri = sip:orange-obs.fr

[auth_reg_orange-obs.fr]
type=auth password=3314C9BA9688C2AA
username = 75B55BTQUHSG@orange-obs.fr

[Biv_Sortie]
type = aor contact = sip:75B55BTQUHSG@orange-obs.fr@orange-obs.fr default_expiration = 3600

[Biv_Sortie]
type = identify endpoint = Biv_Sortie match = orange-obs.fr

[Biv_Sortie]
type=auth username = Biv_Sortie password=3314C9BA9688C2AA

[Biv_Sortie]
type=endpoint context = Isdn_Inbound dtmf_mode=rfc4733
disallow=all allow = g722, alaw, g729
direct_media=no trust_id_inbound = yes send_rpid=yes from_user = 75B55BTQUHSG@orange-obs.fr from_domain = orange-obs.fr language = en allow_subscribe = yes auth = Biv_Exit outbound_auth = Biv_Sortie aors = Biv_Sortie

Question how can I solve this character problem “@”?

2) resolution of the orange-obs.fr DNS.  I am attaching an extract from the documentation that Orange issued in 2015

SIP/Internet is described in RFC3261 and following. THE
SIP/IMS is described by 3GPP standards. It’s not the same SIP. In the Internet world, VoIP machines route SIP messages to the IP addresses of the FQDNs of the SIP URIs
(VoIP domain). In the 3GPP world, SIP messages are routed to an I/P-CSCF (depending on whether we are in interco or in IPBX) which has a different FQDN from the VoIP domain.

BIV SIP

– P-CSCF FQDN: pcscfgm.orange-obs.fr, resolved by DNS
voice
– VoIP domain: orange-obs.fr, not resolved by voice DNS. ex :
INVITE sip:0142277620@orange-obs.fr SIP/2.0
2
 The VoIP/Internet machine will not be able to determine the address recipient of SIP messages.

run the command “nslookup pcscfgm.orange-obs.fr” and note the returned IP address 217.167.210.X
– add this address in the /etc/hosts file of the PBX:
217.167.210.X pcscfgm.orange-obs.fr orange-obs.fr

Note that it works with sip.conf . The current installation is operational with the information provided by /etc/hosts

below the debug in asterisk 19.6

[2023-06-08 13:37:17] DEBUG[185433]: res_config_odbc.c:115
custom_prepare: Skip: 0; SQL: SELECT * FROM ps_auths WHERE id = ?
[2023-06-08 13:37:17] DEBUG[185433]: res_config_odbc.c:134
custom_prepare: Parameter 1 (‘id’) = ‘auth_reg_orange-obs.fr’
[2023-06-08 13:37:17] DEBUG[185433]: res_odbc.c:808
ast_odbc_release_obj: Releasing ODBC handle 0x55855d1977d0 into pool
[2023-06-08 13:37:17] DEBUG[185433]: config.c:3847 ast_parse_arg:
extract uint from [32] in [0, 4294967295] gives [32](0)
[2023-06-08 13:37:17] DEBUG[185433]:
res_pjsip_outbound_registration.c:699 handle_client_registration:
Outbound REGISTER attempt 2 to ‘sip:orange-obs.fr’ with client
‘sip:+3313445XXXX@orange-obs.fr’
[2023-06-08 13:37:17] DEBUG[185433]: res_pjsip/pjsip_resolver.c:475
sip_resolve: Performing SIP DNS resolution of target ‘orange-obs.fr’
[2023-06-08 13:37:17] DEBUG[185433]: res_pjsip/pjsip_resolver.c:502
sip_resolve: Transport type for target ‘orange-obs.fr’ is ‘UDP transport’
[2023-06-08 13:37:17] DEBUG[185433]: res_pjsip/pjsip_resolver.c:545
sip_resolve: [0x55855d769c88] Created resolution tracking for target
‘orange-obs.fr’
[2023-06-08 13:37:17] DEBUG[185433]: res_pjsip/pjsip_resolver.c:174
sip_resolve_add: [0x55855d769c88] Added target ‘orange-obs.fr’ with record type ’35’, transport ‘UDP transport’, and port ‘5060’
[2023-06-08 13:37:17] DEBUG[185433]: res_pjsip/pjsip_resolver.c:174
sip_resolve_add: [0x55855d769c88] Added target ‘_sip._udp.orange-obs.fr’
with record type ’33’, transport ‘UDP transport’, and port ‘5060’
[2023-06-08 13:37:17] DEBUG[185433]: res_pjsip/pjsip_resolver.c:174
sip_resolve_add: [0x55855d769c88] Added target ‘orange-obs.fr’ with record type ‘1’, transport ‘UDP transport’, and port ‘5060’
[2023-06-08 13:37:17] DEBUG[185433]: res_pjsip/pjsip_resolver.c:616
sip_resolve: [0x55855d769c88] Starting initial resolution using parallel queries for target ‘orange-obs.fr’
[2023-06-08 13:37:17] DEBUG[185340]: dns.c:555 ast_search_dns_ex: DNS
search failed for orange-obs.fr
[2023-06-08 13:37:17] DEBUG[185340]: dns_system_resolver.c:154
dns_system_resolver_process_query: DNS search failed for query:
‘orange-obs.fr’
[2023-06-08 13:37:17] DEBUG[185340]: dns.c:555 ast_search_dns_ex: DNS
search failed for _sip._udp.orange-obs.fr
[2023-06-08 13:37:17] DEBUG[185340]: dns_system_resolver.c:154
dns_system_resolver_process_query: DNS search failed for query:
‘_sip._udp.orange-obs.fr’
[2023-06-08 13:37:17] DEBUG[185340]: dns.c:555 ast_search_dns_ex: DNS
search failed for orange-obs.fr
[2023-06-08 13:37:17] DEBUG[185340]: dns_system_resolver.c:154
dns_system_resolver_process_query: DNS search failed for query:
‘orange-obs.fr’

Do you have an idea of what I can do to make this new installation operational?

thank you in advance.

One thought on - Problem With Pjsip

  • The from_user is the username. It can’t contain “@” or the domain. You’ve already set from_domain, so just set from_user to the username.

    You don’t need to do /etc/hosts. Set an outbound_proxy on the endpoint and registration like so:

    outbound_proxy=sip:cscfgm.orange-obs.fr\;lr;\hide

    This will cause the SIP requests to get sent to “cscfgm.orange-obs.fr” but that won’t appear in the SIP signaling.

    You’ll probably have other issues that will require configuration changing, since providers using IMS infrastructure for general SIP always causes that.