My server is on Digital Ocean with a static IP address and not behind a nat. My trunk provides this snippet of code explaining how to properly configure it in asterisk sip
[###-inbound]
type=friend
dtmfmode=auto
host=###
context=inbound
allow=all
insecure=port,invite
canreinvite=no
[###-outbound]
type=friend
dtmfmode=auto
host=###
allow=all
canreinvite=no
Now I can translate some of this with the help of pages like https://wiki.asterisk.org/wiki/display/AST/Migrating+from+chan_sip+to+res_pjsip , https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Configuration_res_pjsip and other many misc Google searches and whatnot.
But the problem is some of these aren’t so easily translatable to pjsip and outbound calls don’t work so it tells me something is still not quite right. My trunk uses IP authentication.
What I have so far is
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
[###-inbound]
type=aor
contact=sip:###
[###-inbound]
type=identify
endpoint=###-inbound
match=###
[###-inbound]
type=endpoint
context=inbound
allow=all
aors=###-inbound
direct_media=no ; canreinvite
dtmf_mode=auto
[###-outbound]
type=aor
contact=sip:###
[###-outbound]
type=identify
endpoint=vitelity-outbound
match=###
[###-outbound]
type=endpoint
allow=all
aors=vitelity-outbound
direct_media=no ; canreinvite
dtmf_mode=auto
Inbound calls work, outbound doesn’t, I’m not sure where I’m going wrong. Any help is appreciated.
I’m not familiar with the pjsip configuration, but it doesn’t help that the chan_sip example they given repeats the bad practice used by most ITSPs in their configuration examples.
In most cases you do not need inbound and outbound entries.
In most cases, they should be type=peer, not type=friend.
canreinvite was renamed to directmedia many many years ago.
In most cases you don’t need insecure=port.
insecure=invite makes no sense if you do not have secret.
If they are using dynamic addresses for you, you need either register (in the general section) or to define a call back extension. It may help if recreate the chan_sip configuration, from first principles, so you are translating something that you understand.
My initial guess is that most, or all, of the type=aor entries are irrelevant.
Initially looking at chan_pjsip.conf.sample, the section headed “OUTBOUND REGISTRATION WITH OUTBOUND AUTHENTICATION” is the one that one would use with typical ITSPs, assuming the lack of secret , and register, for chan_sip, was an oversight.
contact= appears only to be used for incoming registrations, but I know of no ITSP that attempts those.
Also, you say that the configuration doesn’t work, but fail to provide any logging demonstrating a call being rejected.
Given the ITSP is proposing a section name of …-inbound, but is unlikely to include that in the from headers, I think you can safely assume that type=friend serves no useful purpose, compared with type=peer, and you should be trying to translate based on type=peer. Misused, type=friend can reduce security.
Sorry for lack logs, I was exhausted last night when I finally got on here asking for help after work. Anyways I switched from ip auth to traditional username and password auth and so far I’m having better luck. The same provider provided me with different configs for user/pass auth
(I use vitelity as my provider now bought out by voyant and they do have separate inbound and outbound addresses, I honestly haven’t used other providers so I didn’t know that was weird)
Thier copy-and-paste config:
[vitel-inbound]
type=friend
dtmfmode=auto
host=inbound31.vitelity.net
context=inbound
username=###
secret=###
allow=all
insecure=port,invite
canreinvite=no
[vitel-outbound]
type=friend
dtmfmode=auto
host=outbound.vitelity.net
username=###
fromuser=###
secret=###
trustrpid=yes
sendrpid=yes
allow=all
canreinvite=no
How I translated that
[vitelity-auth]
type=auth
auth_type=userpass
password=###
username=###
[vitelity-reg]
type=registration
outbound_auth=###
server_uri=sip:###@inbound31.vitelity.net:5060
client_uri=sip:###@inbound31.vitelity.net:5060
[vitelity-inbound]
type=aor
contact=sip:inbound31.vitelity.net
[vitelity-inbound]
type=identify
endpoint=vitelity-inbound
match=inbound31.vitelity.net
[vitelity-inbound]
type=endpoint
context=inbound
disallow=all
allow=ulaw
auth=vitelity-auth
aors=vitelity-inbound
dtmf_mode=auto
direct_media=no ; canreinvite
; Not behind nat
rtp_symmetric=no
force_rport=no
rewrite_contact=no
[vitelity-outbound]
type=aor
contact=sip:outbound.vitelity.net
[vitelity-outbound]
type=identify
endpoint=vitelity-outbound
match=outbound.vitelity.net
[vitelity-outbound]
type=endpoint
disallow=all
allow=ulaw
auth=vitelity-auth
outbound_auth=vitelity-auth
aors=vitelity-outbound
dtmf_mode=auto
from_user=###
send_rpid=yes
direct_media=no ; canreinvite
trust_id_inbound=yes ; trustrpid
; Not behind nat
rtp_symmetric=no
force_rport=no
rewrite_contact=no
So like I said so far it’s doing good but any advice anyways on my current config would be welcome and as of now it appears to be working for the moment. The last time I tried user/pass registration oubound calls were dicey and mostly failed so that’s why I switched to ip config but I think going back and re-translating user/pass registration better has helped at least for the time being.
PJSIP configuration is extremly easy once you understand the relation between each section. When dealing with outbound trunk authencation who require username and pass word there is something you need to keep on mind, for outbound calls authencation use the outbound_auth option, l have posted a very simple and minimal configuration that works, note the indentify section is not really needed here, as it is used to determines what endpoint an incoming packet is from. Nothing to do with outbound calls
[rapidvox]
type=endpoint
context=from-external
disallow=all
allow=ulaw
outbound_auth=rapidvox
aors=rapidvox
transport=transport-udp-trunk
from_user=ozcank
send_diversion=yes ; Send the Diversion header conveying the diversion
; information to the called user agent (default: "yes")
send_pai=yes ; Send the P Asserted Identity header (default: "no")
send_rpid=yes
trust_id_inbound=yes ; Accept identification information received from this
; endpoint (default: "no")
trust_id_outbound=yes
[rapidvox]
type=aor
contact=sip:sip.rapidvox.com:5060
qualify_frequency=200
[rapidvox]
type=auth
auth_type=userpass
username=ambiorixg12
password=testxx3testxx3
[rapidvox]
type=identify
endpoint=rapidvox
match=sip.rapidvox.com