[mit]

I am experiencing issues with user experience due to delay in audio caused by media traversing the 3CX server. However, we are unable to bypass the 3CX server as the method used for reinviting the media does not comply correctly with RFC 3261 in respect of backward compatibility with RFC 2543. Please see the following topic discussing the matter below:

http://www.3cx.com/forums/media-delay-re-invite-issue-with-unsupported-voip-provider-13075.html

In this discussion we identify that the likely cause of the inability to correctly interwork with the a VoIP provider is that their SBC is enforcing compliance with RFC3261. The following extract from RFC3261 describes the desired behaviour:

Usage of the URI from the To and From fields in the original
request within subsequent requests is done for backwards
compatibility with RFC 2543, which used the URI for dialog
identification. In this specification, only the tags are used for
dialog identification. It is expected that mandatory reflection
of the original To and From URI in mid-dialog requests will be
deprecated in a subsequent revision of this specification.

When the 3CX server is sending a re-invite during a transfer it is attempting a target refreshing invite, which means it is failing on the SBC as the the To and From fields no longer match the original invite.

An option to be able to select whether a VoIP provider would like a target refrreshing invite, or one which complies with RFC 3261, with respect to the backward compatibility for RFC 2543, would hopefully resolve this issue.