PJSIP still has bugs

I think we have a winner:

Sent RTP packet to 10.15.20.171:12104 (type 00, seq 014477, ts 1110542080, len 000160)
Got RTP packet from 208.93.226.13:5634 (type 00, seq 001609, ts 1110542243, len 000160)
Sent RTP packet to 10.15.20.171:12104 (type 00, seq 014478, ts 1110542240, len 000160)
Got RTP packet from 208.93.226.13:5634 (type 00, seq 001610, ts 1110542403, len 000160)
Sent RTP packet to 10.15.20.171:12104 (type 00, seq 014479, ts 1110542400, len 000160)
Got RTP packet from 208.93.226.13:5634 (type 00, seq 001611, ts 1110542563, len 000160)
Sent RTP packet to 10.15.20.171:12104 (type 00, seq 014480, ts 1110542560, len 000160)

10.15.20.171 is the private IP address inside the remote network.
I have no clue what that WAN IP address is. Its not my SIP providers gateway or the Public IP of the phone system.

How does that look different when you do it with chansip.

Hi!

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…

Good luck and have a nice day!

Nick

@jessy5765

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.

1 Like

Agree. I’m not saying they don’t work, I’m saying they were not helpful getting them to work.

I was simply replying to Andrew w/ an example of a provider that didn’t work (for me) with PJSIP along with the disclaimer that it likely is my fault :slight_smile:

@BlazeStudios Okay. I understand that. I very well may have it configured on the PBX incorrectly. I provided the logs that were asked for to the best of my ability.

I added the Local Network to sip settings and still no audio. As for the External Media IP… what is that exactly and where do I need to set it?

Thanks

Seems this might be a bug. Its not only me that is having the exact issue.

That thread was related to a FreePBX bug that was fixed

okay… so maybe its still present in PBXact then possibly. As the other guy mentioned the rtp debug logs seem to be sending traffic to an internal IP and NOT the remote IP. just as mine are above?

Sent RTP packet to 10.15.20.171:12104 (type 00, seq 014477, ts 1110542080, len 000160)
Got RTP packet from 208.93.226.13:5634 (type 00, seq 001609, ts 1110542243, len 000160)

I really dont know. I just need to get this working. I’m reaching for anything.

fwconsole ma list | grep core

core | 13.0.120.3

You are at the latest version like everyone else. I’m not sure (at this time) if this is a bug or a misconfiguration or a misunderstanding.

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. :slight_smile: 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?

1 Like

It’s been two long years, but this feature (“externhost functionality for PJSIP”) finally seems to be coming!!! Joshua Colp has implemented it (https://gerrit.asterisk.org/#/c/6069/)!

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).

Here is one:
Twilio +SIP/TLS only works on chan_sip, but not on pjsip.

I think it’s premature to call it a bug. But it does look like a tricky configuration.