Hi,
I think I probably found an issue with respect to how PJSIP is managing a
dialogs remote target URI.
Essentially, the client is initiating a dialog by sending an INVITE, but
before receiving the 200OK, we receive a 183 session progress. The 183 has
the following header:
Contact: sip:5115038778768769251@99.99.9.999:8064;transport=tls
With it, PJSIP is updating the dialogs remote identity, which is correct.
But in the 200 OK that follows it, the header changes to:
Contact: sip:5115038778768769251@99.99.9.999:8064;transport=tls;abi=giF9
And when dealing with the response, PJSIP isn't updating the dialog remote
identity because the To header didn't change. But the SIP RFC says that:
When a UAC receives a 2xx response to a target refresh request, it
MUST replace the dialog's remote target URI with the URI from the
Contact header field in that response, if present.
Is my analysis correct or am I missing something?
Thank you
João Ramos
Hi,
I think I probably found an issue with respect to how PJSIP is managing a
dialogs remote target URI.
Essentially, the client is initiating a dialog by sending an INVITE, but
before receiving the 200OK, we receive a 183 session progress. The 183 has
the following header:
Contact: <sip:5115038778768769251@99.99.9.999:8064;transport=tls>
With it, PJSIP is updating the dialogs remote identity, which is correct.
But in the 200 OK that follows it, the header changes to:
Contact: <sip:5115038778768769251@99.99.9.999:8064;transport=tls;abi=giF9>
And when dealing with the response, PJSIP isn't updating the dialog remote
identity because the To header didn't change. But the SIP RFC says that:
When a UAC receives a 2xx response to a target refresh request, it
MUST replace the dialog's remote target URI with the URI from the
Contact header field in that response, if present.
Is my analysis correct or am I missing something?
Thank you
--
*João Ramos*