Chan_sip to chan_pjsip

The trunk provider says that they have a bunch of IPs from which they are about to send me the inbound calls. So they said i might need to change to pjsip because chan_sip does not allow that. But is there anyway that I could allow the bunch of IPs from which they will send me the calls under the same trunk name example: [Trunk-XYZ]? or I need to create several entries with the different different IPs?

You use multiple match lines in the type=identify section that is linked to the endpoint. The endpoint names is the name that is used to form the channel name (and for outgoing calls, is how the destination is specified), so I assume that is what you mean by trunk name.

[Section name corrected]

hey, thank you david.

so say for example i have this →

[trunk]
register => username:password@sip.trunk.com
allow=ulaw
type=friend
secret=password
username=username
host=sip.trunk.com
dtmfmode=rfc2833
context=inbound
canreinvite=no
allow=ulaw
insecure=port,invite
fromdomain=sip.trunk.com

Now here, what i am missing to be able to or what i should add to be able to receive inbound calls from multiple IPs that the provider sip.trunk.com is planning to push to my server?

That is a chan_sip configuration. It is not possible to do such a thing in chan_sip. You have to create individual peers for each IP address.

got it leader! thank you!

This is a sip.conf configuration, not a pjsip.conf one. It also contains many examples of bad practice that are typical of configurations suggested by providers. There is a tool for creating a first cut pjsip configuration, but you should first clean up the sip.conf one. You will almost certainly be better off starting from the suggested provider trunk configuration in res_pjsip Configuration Examples - Asterisk Project - Asterisk Project Wiki

In terms of cleaning up:

type should be peer (especially if you are using an arbitrary name like “trunk”, which the peer won’t use.

username doesn’t do what most providers think it does, so is probably not useful. It is mainly for incoming registrations, not outgoing ones.

canreinvite should be directmedia

You should have a disallow before your allows.

Having two allows for the same codec doesn’t make sense.

Most providers don’t need insecure=port

register should be in the general section.

1 Like

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