[Yxa-devel] Changing transport to TLS/TCP

[Johan Vikman]

Hi Fredrik,

See my response below.

Thanks for your help!

BR,
Johan

On Sep 2, 2013, at 1:02 PM, Fredrik Thulin <fredrik at thulin.net> wrote:

> On Mon, 2013-09-02 at 12:26 +0200, Johan Vikman wrote:
>> Hi Fredrik,
>> 
>> Of course, below I describe one way this could happen, the yxa stack is used in the LRF node.
>> 
>>  UE                          E-CSCF                                                                          LRF       PSAP
>> 1 |--SIP INVITE TCP-->|                                                                                     |              |
>> 2 |                                     |--SIP INVITE TCP    -->                                            |              |
>> 3 |                                     |<-- SIP 300 Multiple Choices using TLS/TCP -- |              |
>> 4 |                                     |--SIP INVITE TLS/TCP------------------------------------------->|
>> 5 |                                     |--200 OK --------------------------------------------------------------|
>> 6 |<--- 200 OK -----------|                                                                                     |              |
>> 
>> 1. UE calls 112
>> 2. E-CSCF does not know which PSAP to forward to, so it asks LRF
>> 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.
>>     Because the PSAP is uing SIPS, the LRF has to use TLS/TCP for the response.
>> 4. E-CSCF forwards SIP INVITE to PSAP
>> 5. PSAP 200 OK to E-CSCF
>> 6. E-CSCF 200 OK to UE
>> 
>> 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.
> 
> Thanks - I think I understand now.
> 
> So, really, I don't think the requirement is for the 300 response in
> step 3 to be sent using TLS/TCP (SIP does not support upgrading from
> TCP/UDP for the response, IIRC). I think the requirement is that the
> E-CSCF uses TLS when it connects to a TLS capable PSAP in step 4.

That was my guess to, but the product owner wants the transport to change in the 300 response.

Digging through the sip-imeplementors list and found an entry that supports your answer.

https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-June/019447.html

"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."
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.

> 
> In that case, it should be as simple as making sure the LRF returns SIPS
> URIs (and not SIP URIs) in the 300 response of step 3. That will result
> in the E-CSCF using TLS in step 4 when it sends the INVITE to the PSAP.
> 
> /Fredrik
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.su.se/pipermail/yxa-devel/attachments/20130902/f2c4a6f4/attachment.html>