Possible bug in "target refresh requests"

JR
João Ramos
Thu, Jan 25, 2018 7:32 PM

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*