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 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.