Migrate from sip to pjsip

I followed how to’s on the web to get my asterisk environment running. and resulted in a sip configuration.

I was told in some other post that that is outdated. and now when i moved on to home assistant i found a nice asterisk integration that uses the web socket to connect. that requires pjsip.

So I installed an asterisk home assistant instance with a clean autoconfigured pjsip configuration.

I have some questions. I need to rewrite the sip connections in sip.conf and users.conf to the new pjsip configuration right? and can keep the extentions.conf file.
But how is NAT arranged? I cant find anything on that.

ps.
I found a tool called sip_to_pjsip.py but that has failing dependencies.

NAT is arranged in your router, as was the case for chan_sip.

The options for compensating for your being inside NAT are the four starting here:

The options that you might need to compensate for the failure of the other side to correctly compensate for NAT are the three starting here:

Note that the nat= option in chan_sip confuses many people; it isn’t there for Asterisk behind NAT, but rather for the peer being behind NAT and failing to compensate for that.

This:

also provides support for NAT for media with suitable clients, and corresponds to:

I believe it is particularly important for webrtc and therefore websockets, but I haven’t personally researched it.

I didn’t think many serious users use users.conf, so I don’t know about that. You will need to change the technology name in dialstrings and there are differences in the possible resource parts, in extensions.conf and other places that use them.

Functions for accessing low level information relating to SIP are different, and the one that particularly catches people out is that adding and reading headers is done differently.

I found a tool called sip_to_pjsip.py but that has failing dependencies.

Careful! I actually recommend you not use this, or if you do use it, be very careful, because this is an incomplete tool that will generate false, nonsensical data. It’s a helpful start, but you can’t convert your sip.conf in one step and be done. You’ll have a lot of cleanup work to sort through.

It may be better to start fresh with PSJIP config and not use that script, because it may just confuse you and set things back further. (I used that tool and it took about 6 months to sort through all the aftermath fully).

Generally doing anything except starting from first principles and understanding how things work will produce bad configurations. Most of the chan_sip configurations I’ve seen here are based on ones provided by service provides who don’t really seem to understand how things work. You are almost certainly trying to convert something that was badly designed in the first place. In particular lax security can appear to make things work.

Oke i could work on my asterisk system. I Migrated from sip to jpsip. Only two issues. I cant connect to TLS with my softphone. But cant write about it because im back to SIP due to issue two.

My Grandstream FXO does not hang up the call when i hang up the phone.
I went back to SIP to verify and that works fine.

Some one has a solution?

Please provide the “pjsip set logger on” type logging.

(This sounds like a bad contact header, which is generally NAT related.)

Show us the pjsip configurations for the endpoint(s) and all their sections. What model is the Grandstream?

pjsip set logger on gives to much information from bots trying to make a call. I dont know where im looking for,

[transport-udp-nat]
type=transport
protocol=udp
bind=0.0.0.0
local_net=192.168.5.0/24
local_net=192.168.2.0/24
local_net=10.8.0.0/24
local_net=127.0.0.1/32
external_media_address=my.h-o-s-t.name
external_signaling_address=my.h-o-s-t.name


[fxo]
type=endpoint
context=pstn-incoming
disallow=all
allow=alaw
callerid=fxo
transport=transport-udp-nat
auth=fxo
aors=fxo

[fxo]
type=auth
auth_type=userpass
password=1234
username=fxo

[fxo]
type=aor
max_contacts=1

Without the logging for a failed call, I’d need very detailed information about your network topology. I generally find that the logging is a much more reliable source, and most people seem to be able to extract the call.

You probably need much better firewalling if the logs are overwhelmed with toll fraud attempts.

I have fail2ban enabled. I could use a other port. :face_with_diagonal_mouth:

I have now reanabled the sip config for the grandstream on a diffrent port.

The grandstream is connected with the wan port to my local lan. With a virtual bridge to my asterisk virtual machine.

Whitelisting is your friend.

Whitelist your SIP provider, drop everything else.

Whitelist. My mobile phone. That can be connected from anywhere?

Probably not everywhere.

Maybe block off certain countries that are problematic for you. Like China, Russia, Iran, etc.

Maybe collecting a days worth of hostile IP addresses and looking up the netblocks on Arin.net would reduce the problem to more manageable levels.

Many find ‘fail2ban’ is also a help.