<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Fredrik,<div><br></div><div>See my response below.</div><div><br></div><div>Thanks for your help!</div><div><br></div><div>BR,</div><div>Johan</div><div><br></div><div><div><div>On Sep 2, 2013, at 1:02 PM, Fredrik Thulin <<a href="mailto:fredrik@thulin.net">fredrik@thulin.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Mon, 2013-09-02 at 12:26 +0200, Johan Vikman wrote:<br><blockquote type="cite">Hi Fredrik,<br><br>Of course, below I describe one way this could happen, the yxa stack is used in the LRF node.<br><br> UE E-CSCF LRF PSAP<br>1 |--SIP INVITE TCP-->| | |<br>2 | |--SIP INVITE TCP --> | |<br>3 | |<-- SIP 300 Multiple Choices using TLS/TCP -- | |<br>4 | |--SIP INVITE TLS/TCP------------------------------------------->|<br>5 | |--200 OK --------------------------------------------------------------|<br>6 |<--- 200 OK -----------| | |<br><br>1. UE calls 112<br>2. E-CSCF does not know which PSAP to forward to, so it asks LRF<br>3. The LRF knows where the UE is and knows that for this case a PSAP using SIPS is configured for that area, and also that a location should be provided.<br> Because the PSAP is uing SIPS, the LRF has to use TLS/TCP for the response.<br>4. E-CSCF forwards SIP INVITE to PSAP<br>5. PSAP 200 OK to E-CSCF<br>6. E-CSCF 200 OK to UE<br><br>My problem here is at message #3, the response back to E-CSCF, I do not know how to make yxa use TCP/TLS instead of TCP, or even if it is allowed to change transport in this fashion.<br></blockquote><br>Thanks - I think I understand now.<br><br>So, really, I don't think the requirement is for the 300 response in<br>step 3 to be sent using TLS/TCP (SIP does not support upgrading from<br>TCP/UDP for the response, IIRC). I think the requirement is that the<br>E-CSCF uses TLS when it connects to a TLS capable PSAP in step 4.<br></blockquote><div><br></div>That was my guess to, but the product owner wants the transport to change in the 300 response.</div><div><br></div><div><div>Digging through the sip-imeplementors list and found an entry that supports your answer.</div><div><br></div><div><a href="https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-June/019447.html">https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-June/019447.html</a></div><div><br></div><div><pre>"The sentence "The ACK MUST be sent to the same address, port, and
transport to
which the original request was sent" refers to 3xx-6xx responses."
</pre></div><div>I will take this back and discuss another solution, in case the location needs to be provided back to the E-CSCF, one could provide a https-URI in the Geolocation header instead of providing the location in the SIP body.</div><div><br></div><blockquote type="cite"><br>In that case, it should be as simple as making sure the LRF returns SIPS<br>URIs (and not SIP URIs) in the 300 response of step 3. That will result<br>in the E-CSCF using TLS in step 4 when it sends the INVITE to the PSAP.<br><br>/Fredrik<br><br><br></blockquote></div><br></div></body></html>