PJSIP: Cannot place calls without "from_user" set

Asterisk Asterisk SIP
1

I am trying to configure a basic sip trunk and sip user in two VMs. Currently, I cannot place outbound calls with from_user=username enabled in pjsip.conf on the sip user vm. This is an issue because it overrides the caller ID. Is this normal behavior, and if so, is there a way to authenticate without it?

on the pbx vm

@1001
[Jul 10 11:44:45] WARNING[1780]: res_pjsip_outbound_authenticator_digest.c:633 digest_create_request_with_auth: 1001:10.137.0.44: Authentication credentials not accepted by server. Credential failed to authenticate (PJSIP_EFAILEDCREDENTIAL)

on the sip vm

 NOTICE[1501]: res_pjsip/pjsip_distributor.c:688 log_failed_request: Request 'INVITE' from '"Anonymous" <sip:anonymous@anonymous.invalid>' failed for '10.137.0.43:5060' (callid: 3815215c-ffa3-4f06-9214-021940e5fd2c) - No matching endpoint found
[Jul 10 11:39:02] NOTICE[1501]: res_pjsip/pjsip_distributor.c:688 log_failed_request: Request 'INVITE' from '"Anonymous" <sip:anonymous@anonymous.invalid>' failed for '10.137.0.43:5060' (callid: 3815215c-ffa3-4f06-9214-021940e5fd2c) - Failed to authenticate

pjsip.conf on pbx

[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0:5060

[auth_1001]
type=auth
auth_type=userpass
username=1001
password=password

[1001]
type=aor
max_contacts=1
contact=sip:10.137.0.44:5060
[1001]
type=endpoint
transport=transport-udp
;remote_hosts=10.137.0.44:5060
auth=auth_1001
aors=1001
disallow=all
outbound_auth=auth_1001
allow=ulaw
context=outbound
default_from_user=1001
;trust_id_outbound=yes
;insecure=invite
;dtmfmode=auto
;fromuser=1001
[1001-registration]  ; ADD REGISTRATION
type=registration
outbound_auth=auth_1001
server_uri=sip:10.137.0.44:5060
client_uri=sip:1001@10.137.0.44:5060
expiration=120
endpoint=1001

on sip

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060

; ======== 1001 Configuration ========
[auth_1001]
type=auth
auth_type=userpass
username=1001
password=password

[1001]
type=aor
max_contacts=1

[1001]
type=endpoint
transport=transport-udp
auth=auth_1001
aors=1001
disallow=all
allow=ulaw
context=internal
;trust_id_outbound=yes
insecure=invite
trust_id_outbound=yes
trust_id_inbound=yes
inbound_auth=auth_1001
trust_connected_line=yes
;dtmfmode=auto
;force_rport=yes
;rewrite_contact=yes
;direct_media=no
; ======== 1002 Configuration ========
[auth_1002]
type=auth
auth_type=userpass
username=1002
password=yourpassword

[1002]
type=aor
max_contacts=1

[1002]
type=endpoint
transport=transport-udp
auth=auth_1002
aors=1002
disallow=all
allow=ulaw
context=internal
;force_rport=yes
;rewrite_contact=yes
;direct_media=no
2

This is expected. Instead convey callerid using the other more preferred methods, such as RPID (send_rpid=yes) or P-Asserted-Identity (send_pai=yes).

3

Thank you. My goal is to get it setup so that I can change the caller ID in the dialplan (for sanctioned pentesting engagements). Is there any way one can do that and still have it authenticate with only userpass auth?

4

Yes. By transporting callerid like I mentioned. Callerid gets sent in separate headers, not in the From header.

5

What do these terms mean? Trunk is not a term used in the SIP RFC, and user means the part of the URI before the @, if present.

Although this combination isn’t actually forbidden, it is almost always an error. You appear to have no type=register to use against the max_contacts.

If you know enough to use contact=, you should be matching by IP address, not by user name.

In many cases of two PABXes connected together, you know static addresses for both ends, in which case type=register isn’t needed for either.

This means nothing on chan_pjsip (and there are better ways now available on chan_sip). On chan_sip it causes secret to generate the equivalent of both auth=SameSomething and outbound_auth=same_something (although there are some more complex cases).

I don’t believe this exists, given that auth= refers to the inbound direction only.

6

sorry, I am new to anything voip or phone related, and was working with various outdated configs I found online.

My goal was for one to emulate a sip trunk like one of the various sip trunk providers for rent online. My understanding is that one is provided with credentials in username and password format, and one connects using the credentials and hostname. I asked support for one if they require outbound registration and they said no, so that is what I am struggling with.

7

Okay, I used the exact configuration on this page of the documentation PJSIP Configuration Wizard - Asterisk Documentation

The everything seems to be in order, but when I try to place calls, it still fails to authenticate. Also now as well, when defining a from_user, it does not register the call on the vm hosting the trunk.

8

If they don’t require outbound registration, it means that you have told them your IP address by non-SIP means. Typically, in such cases, they identify you by that IP address, not from the from user, and, with such a provider, you wouldn’t have the current problem.

Note that, these days, with most real providers, you will need to go through hoops before you can present them with a caller ID other than the one they allocated to you, as industry and regulators are fighting back against the misuse of fake caller ID for scamming and spamming.

Real providers are almost always identified by their IP address, and I doubt any are identified by the From user.

9

Real providers actually allow both. There are some that only allow IP based authentication but there are plenty of real providers that allow registration.

10

I think you have mixed up my “are identified by” with “identify by”. Both options are offered to allow the provider to identify the customer, but the vast majority of providers require the customer to look at the IP address to determine that a request came from the provider. The OP has more symmetry than the real world.

11

Actually the OP has a bad endpoint on the sip VM. There is no insecure option in chan_pjsip and there is no inboud_auth setting. These bad settings can most like stop the endpoint from being available or even loaded.

12

I mentioned both those.

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.