Hi all,
Not what you think this is - usually, one way audio doesn’t defeat me but this looks a little non standard. The advantage is that I am also the SIP Provider, and PBX Maintainer. I have an Asterisk 13/FPBX 13 install up, and I’ve brought up a SIP trunk to our Provider FreeSwitch servers. For outbound calling, everything works well, and audio flows in both directions.
For an inbound call, this is where it gets into never-before-seen territory. From a pcap on the Provider servers everything looks excellent, they INVITE, Asterisk replies back with 100 Trying, then 183 Session Progress (with media SDP). After the 183, media negotiates with a-law and I can see two RTP flows (indicating, two way audio), then we see Asterisk sending 180 Ringing (twice) and I assume that with Early-Offer the media comes up to carry the “ringing audio”. All normal so far… After the two 180 Ringings, Asterisk sends a 200 OK (I guess this is when I pick up the call), and the provider sends an ACK. That 200 OK also has media SDP in it. After the Provider sends the ACK, Asterisk brings up a G722 RTP on the same source port, but the Provider doesn’t seem to bring up it’s RTP back to me (assuming the first a-law flow was torn down).
So, I know it’s normal to be able to change RTP streams and so forth during calls - is this a RE-INVITE? I do have canreinvite set to no in Asterisk, so it’s not bringing up a new RTP directly between the endpoint (or, it shouldn’t be).
Well, I suck at explaining so here’s a link to a stripped back overview of the pcap. As the arrows on it dictate … Right hand side is the Provider server, left hand side is the PBX. Trunk is PJSIP. Provider is FreeSwitch. Codec preference is a-law, u-law, g722. Both sides, and endpoint support these codecs.
Thanks.