You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation allows only for request URI matching and To matching (if isLoopback is set).
However, we have encountered cases in which a valid INVITE request received by the right SipPhone is formed with a E164 number /domain combo of the user contained within the SIP URI of the From header (instead of the username/domain combo), which results in a request mismatch and for the request to be dropped.
In order to provide to the tester to add additional request matching mechanisms and to provide extensibility without actually changing the SipSession/SipPhone class, we need to introduce a new way of handling these cases.
The text was updated successfully, but these errors were encountered:
The current implementation allows only for request URI matching and To matching (if isLoopback is set).
However, we have encountered cases in which a valid INVITE request received by the right SipPhone is formed with a E164 number /domain combo of the user contained within the SIP URI of the From header (instead of the username/domain combo), which results in a request mismatch and for the request to be dropped.
In order to provide to the tester to add additional request matching mechanisms and to provide extensibility without actually changing the SipSession/SipPhone class, we need to introduce a new way of handling these cases.
The text was updated successfully, but these errors were encountered: