Skip to content

Conversation

@benceszigeti
Copy link
Collaborator

https://www.rfc-editor.org/rfc/rfc3261.html#section-12.1.1

“If the request that initiated the dialog contained a SIPS URI in the
Request-URI or in the top Record-Route header field value, if there was
any, or the Contact header field if there was no Record-Route header
field, the Contact header field in the response MUST be a SIPS URI.”

@benceszigeti
Copy link
Collaborator Author

Submitting for an initial review before opening an upstream PR.

https://www.rfc-editor.org/rfc/rfc3261.html#section-12.1.1

"If the request that initiated the dialog contained a SIPS URI in the
Request-URI or in the top Record-Route header field value, if there was
any, or the Contact header field if there was no Record-Route header
field, the Contact header field in the response MUST be a SIPS URI."
ct_username = ctu.user.s;
ct_username_len = ctu.user.len;
ct_type = ctu.type;
if (ct_type == SIPS_URI_T) prefix_len += 1;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If RURI and Top RR are sip:, meanwhile the Contact header is sips:, then we should send out sip: in the Contact header if I understand correctly (Contact header only matter when RR is empty). In that case, this part may be broken, as it will calculate with the length of sips:, but later, it will send out sip: with it. I have to rethink this part.

@benceszigeti benceszigeti added enhancement New feature or request wontfix This will not be worked on labels Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request on hold wontfix This will not be worked on

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants