That IP belongs to Broadvox/OnVoy, a VoIP provider…
RTP traffic doesn’t have to come with the same server you established the SIP connection with…
For some providers it is but for others (like for example Flowroute) it is not… This is why you frequently can’t put any restrictions on where your RTP traffic comes from, that you have to allow it from everywhere…
You need to provide an actual SIP level debug so the SIP messages are present and the SDP/contact IPs can be looked at and we can see what Asterisk is using for things.
As well, Chan_SIP and Chan_PJSIP have their own methods of handling things behind NAT. Just because it works with Chan_SIP and not Chan_PJSIP doesn’t immediately make it a bug. Are all your Chan_PJSIP network settings correct? Does it know what the local networks are? Does it know its proper external media IP?
If you are able to get audio over Chan_SIP but not Chan_PJSIP, I don’t think this is an issue with the RTP media IPs not being allowed via the firewall because they are. This is looking more like misconfigured NAT/network settings for Chan_PJSIP.
@tm1000 - I was unable to get chan_pjsip to work with either Vitelity or FlowRoute. They provided instructions for chan_sip (which worked fine). I’m not an expert, so I only worked on it for a hour or so before giving up. Their support was not helpful and the alternative worked so I didn’t pursue. This was 6+ months ago.
I do use chan_pjsip for all my local extensions. I like the multiple devices on a single extension option. I haven’t had any issues with chan_pjsip in this context.
Chan_SIP and Chan_PJSIP are SIP stacks for Asterisk, that’s it. SIP. Most providers, including Vitelity and Flowroute, provide basic, minimal, generic SIP settings for Asterisk. All of which are generally based on 1.6 to 1.8 era of Asterisk. Mainly because those settings haven’t changed in over a decade. Some have been replaced like “canreinvite” and “username” but those old settings continue to work in all current versions of Asterisk.
A provider that doesn’t know what PJSIP is or doesn’t have instructions for PJSIP trunks doesn’t mean they don’t “support” PJSIP as it is SIP. It just means the provider is not keeping current with Asterisk releases and the changes that happen with them.
Okay should I open a PBXact ticket then? Noone seems to know what is going on. I said I would give it a shot to help you guys out in proving that it does not have issues but clearly something is going on. Chan_SIP works, PJSIP remote no workie.
I dont really know what to get you guys in order to help and all anyone here has to say is… misconfig somewhere. My client is going live next week and this corrected.
Sorry I am trying to help you but you are just going to have to wait at this time for help from anyone. If you open a PBXact ticket they will tell you to use chan_sip. That doesnt mean that there is an internal issue with PJSIP it’s just the team will go with whatever is easier for you as a client to get moving forward.
Eventually we will look into this but for other people it is work fine (outbound and inbound trunks) which is why i tend to lean towards something with your configuration other than jumping into a “this is a pjsip bug”
I know you are. I’m not whining, just trying to get the importance across that I need to get this working. I cant use chan_sip because these are remote extensions for the same person which is why PJSIP mattered. Would it help if I said not even vmail has voice when trying to access it?
The functionality of using dynamic host addresses for external_media_address and external_signaling_address should therefor soon be available. Looks like Asterisk 14.7.0 and 13.18.0 are the versions that will come with this feature.
From what I understand the refresh time will be configurable in /etc/asterisk/dnsmgr.conf (like the “externrefresh” in chan_sip).