SOLVED First instance of speech is missed

[fusionpbxnoaudio]

I have a weird problem on internal calls alone, i.e between extensions, the first hello of the callee is never heard by the caller - I just did a packet capture and the first RTP packet alone has a huge delta, it also has a status message saying Payload changed to PT=8 - this message occurs on all internal extension to extension calls on the first RTP packet. There is also a frequency drift in wireshark? I don't know whether it is relevant or not, but the quality of the audio is not acceptable - there are cracks and pops in the voice and not pleasant to the listener.

However if a call is established from the internal extension to a PSTN gateway, the first RTP packet doesn't have the status message saying payload changed to PT=8, the external PSTN gateway only accepts PCMA. The outbound and inbound codecs on the freeswitch is set to PCMA. The sip clients also send PCMA as the only codec during invite. The quaity of audio when the call is made to PSTN is far superior than internal extension to extension calls.

 

[bcmike]

It would be nice to know what the payload type was changing from. I would be to try and change the acceptable codecs on your phones to both Ulaw and Alaw. My thoroughly uneducated guess is that there's something internally demanding Ulaw. As I said its just a guess but it's pretty trivial to just give it a try and see what happens.

 

[fusionpbxnoaudio]

It is changed from unassigned to PCMA - that is my inference from the wireshark RTP stream analysis.

 

[bcmike]

I'd still just set two phones up with Ulaw and see if you get a different result. If not we can cross that off the list. I guess I'd be trying to get to something that works and then try to back track and figure out why Alaw doesn't. We're also booth assuming its a codec issue.

 

[fusionpbxnoaudio]

with ulaw on the phones, the call doesn't complete because freeswitch is configured only with PCMA as the only preferred codec. the PSTN here supports only PCMA, just to clarify only the first Hello or what ever is spoken/transmitted in the first packet which has the huge delta is missed out, rest of the conversation is heard, abeit with jitter losses.

The payload setting might be a shift from the ringback tone to actual voice audio codec.

When a call is made from the extension to an external gateway - the "unassigned" is not present in the payload field of wireshark capture.

On the log file I find this for both internal calls and for external calls.

2322c122-070a-11ec-9142-c727a551bb6a 2021-08-27 13:10:34.450960 [DEBUG] switch_ivr_originate.c:1333 Raw Codec Activation Success L16@8000hz 1 channel 20ms 2322c122-070a-11ec-9142-c727a551bb6a 2021-08-27 13:10:34.450960 [DEBUG] switch_core_codec.c:223 sofia/internal/11@192.168.1.2 Push codec L16:100 2322c122-070a-11ec-9142-c727a551bb6a 2021-08-27 13:10:34.450960 [DEBUG] switch_ivr_originate.c:1407 Play Ringback Tone [%(400,200,400,450);%(400,2000,400,450)] 2322c122-070a-11ec-9142-c727a551bb6a 2021-08-27 13:10:34.470948 [DEBUG] sofia.c:7325 Channel sofia/internal/11@192.168.1.2 entering state

 

[fusionpbxnoaudio]

I just made another test of capturing packets - this time, I just rang the phone without answering it. The first packet still had the high delta - so it appears that the first packet with high delta is NOT the voice packet but ring back tone. I guess the issue is something else.

 

[fusionpbxnoaudio]

The first part of speech lost is mostly due to the client behind NAT and the inward rtp port doesn't open up until the client establishes a connection with the server

 

[bcmike]

The first part of speech lost is mostly due to the client behind NAT and the inward rtp port doesn't open up until the client establishes a connection with the server

All of my clients are behind various NAT devices and I've never run into this issue. I wonder if it's possible to try a different gateway or possibly tune the port mapping?

 

[fusionpbxnoaudio]

you may be right, I thought it was due to the nature of symmetric NAT which was causing a slight delay in RTP ports being opened. I just changed the setting on the router to a full cone NAT, - I have done few more things like disabling instant ringback - with this setup the RTP ports take a solid 5-6 seconds to be established (with late negotiation enabled). Could you elaborate what you mean by tuning port mapping - you mean port forward on the router or something else?

 

[bcmike]

you may be right, I thought it was due to the nature of symmetric NAT which was causing a slight delay in RTP ports being opened. I just changed the setting on the router to a full cone NAT, - I have done few more things like disabling instant ringback - with this setup the RTP ports take a solid 5-6 seconds to be established (with late negotiation enabled). Could you elaborate what you mean by tuning port mapping - you mean port forward on the router or something else?

No not port forwarding, I should have said nat mapping. On some routers they let you tune the timers on the nat mappings, so for example you may have a timeout on how long a UDP mapping is left open, etc. I'm not sure if that's exactly your problem as you're saying it takes a long time to initiate a connection, however the answer might be in the timers somewhere. Also be sure to turn off any nonsense helpers like SIP ALG, etc.. Maybe there's some sort of packet inspection that's delaying the connection, its hard to say.

It might be a useful experiment to try a different gateway device if possible. Pfsense always seems to handle these things well.

 

[fusionpbxnoaudio]

ALG is disabled, I connect via TLS - the issue is with the RTP port which gets opened randomly for every call. I figured out that this random port for media causes an issue i.e the client sends out some port number as its listening RTP port, but symmetric NAT maps it to something else, freeswitch tries to correct it by sending it to the correct RTP port - I can see this from the logs. This was causing the delay in establishing audio port - during which the human on other side speaks assuming things have been established and audio gets missed. Even with full cone NAT, there are issues with some soft phone clients, so I have made them listen on a fixed RTP port and port forwarded it - with this RTP is established quickly and all are happy.