setOverrideHostAndPort not respected when sending OPTIONS response

[resiprocate]

setOverrideHostAndPort not respected when sending OPTIONS response

[sgodin]

Sorry for the slow response. We will leave this issue open, until someone has a chance to investigate.
Scott

[cyr2242]

Hi, IMHO the contact header in responses from the UAS carries the uri to be used in the following requests but only for the current dialog. Due the OPTIONS requests are, by default, out of a dialog, it won't have any sense to answer with a different uri if the first OPTIONS request was able to reach, unless you want to comunicate, for example, a redirection with a 3XX response: https://datatracker.ietf.org/doc/html/rfc3261#section-11.2. In this case, the overwriting of the contact header in responses to OPTIONS might be allowed, therefore the comments: "Contact header is not required for Requests that do not form a dialog" at line 1091 of Dialog.cxx and "in general, this should not create a Contact header since only requests ... " at line 359 of Helper.cxx (Helper::makeResponse method) are nearly a little wrong and maybe it would be possible to do some kind of treatment with the contact header in the response to OPTIONS at that point. Just my 2 cents. Regards.

[rjjkm]

To reiterate, the use case is running from a containerized environment. For example, the UAC sends an OPTIONS request to a K8s NodePort address which get routed to a SIP UAS container application. To allow routing back to the UAC the Contact header in the response must be set to the K8s NodePort address and not the container's address. The latter is not visible to the UAC.

I have worked around the issue by replacing the Contact header with the MasterProfile host and port override:
// Replace the stack generated Contact header with the override
response->header(resip::h_Contacts).front() = resip::NameAddr(m_dum->getMasterProfile()->getOverrideHostAndPort());

I am okay with using the workaround however if this not accepted as a defect I would suggest clarifying the documentation/code comments since the Options response is not entirely based on current MasterProfile settings.

Thank you

[sgodin]

I agree it should use the override host and port from the master profile. We would gladly accept a pull request fix for this, otherwise it will need to wait for someone with some cycles. :) Thanks for posting the workaround. Scott

…

On Mon, Aug 2, 2021 at 4:34 PM rjjkm ***@***.***> wrote: To reiterate, the use case is running from a containerized environment. For example, the UAC sends an OPTIONS request to a K8s NodePort address which get routed to a SIP UAS container application. To allow routing back to the UAC the Contact header in the response must be set to the K8s NodePort address and not the container's address. The latter is not visible to the UAC. I have worked around the issue by replacing the Contact header with the MasterProfile host and port override: // Replace the stack generated Contact header with the override response->header(resip::h_Contacts).front() = resip::NameAddr(m_dum->getMasterProfile()->getOverrideHostAndPort()); I am okay with using the workaround however if this not accepted as a defect I would suggest clarifying the documentation/code comments since the Options response is not entirely based on current MasterProfile settings. Thank you — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#168 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVU2UJ4I3DBPPJ2P65KRBDT236MVANCNFSM4VWPQEWQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .