Hi Fredrik,

See my response below.

Thanks for your help!

BR,
Johan

On Sep 2, 2013, at 1:02 PM, Fredrik Thulin <fred...@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
> 
> 

_______________________________________________
Yxa-devel mailing list
Yxa-devel@lists.su.se
https://lists.su.se/mailman/listinfo/yxa-devel

Reply via email to