In our environment , we make an outbound call to external number whose phone is setting VoLTE .
When external user answered this call , then the FreePBX prompt “number-not-answering” and this call was ended .
The following picture was captured in FreePBX when this issue occour .
Unless an artifact of your test, it’s strange that there is no outbound RTP shown. If using default ports, 5160 would be chan_sip.
But if you have pjsip on that port: I’ve had trouble where a 180 with SDP was not processed correctly (the SDP was ignored). If that’s your issue, it’s conceivable that China Mobile ended the call for lack of incoming RTP. In that case, configuring the trunk to use chan_sip may fix it.
Otherwise, look at the headers on the 487. There may be a Warning or custom header that gives a clue as to what is wrong.
Also, though unlikely, one of the extra codecs in your INVITE could be causing trouble – see if allowing only alaw helps.
Is this issue specific to VoLTE (there is no trouble calling a non-VoLTE phone using the same trunk)? If so, do you expect a wideband connection using G.722? Or would you need AMR-WB (not present in the INVITE)?
My experience is worthless. Apart from knowing what VoLTE stands for, I have never touched it. You may benefit from a SIP proxy or an SBC that gives very fine control over SIP parameters. I wouldn’t know where to start.
IMHO, it’s unlikely that maxptime is the trouble. First, I’ve never seen a provider fussy about a 150 ms value. Also, if they did reject the call for that reason, one would not expect that to occur only after sending you some RTP.
Don’t give up. First, look at that 487 response for a clue as to what is wrong. You may not find one, but it’s easy to look. Click on the packet in Wireshark, expand the line ‘Session Initiation Protocol (487)’, then expand Message Header. You’ll see all the headers.
If there is no information there, check whether any RTP was sent back to China Mobile during the ~950 ms interval between the 180 and the 487. (It may be there but Wireshark may have failed to display it.) If there is no RTP or it’s not alaw, try to fix that (or report details).
Also, please try setting the trunk to allow only alaw, or allow only g722 and alaw. It’s conceivable that China Mobile tries to set up one of the other codecs but later gets an error. Of course, with only alaw you won’t get a wideband connection, but it’s better than having the call fail.
If you still have trouble, I recommend setting up an IP phone, softphone or SIP app to connect to China Mobile directly (not using the PBX). If that works ok with a VoLTE connection, we can compare the SIP traces and try to make Asterisk look the same. If it also fails in the same way, it won’t be sending a large maxptime and you can update your ticket with China Mobile using that example.