From johan.vikman at mobilearts.com Mon Sep 2 11:20:56 2013 From: johan.vikman at mobilearts.com (Johan Vikman) Date: Mon, 2 Sep 2013 11:20:56 +0200 Subject: [Yxa-devel] Changing transport to TLS/TCP Message-ID: <64A53ACC-AD14-4B2B-81DD-DFE702FAFD11@mobilearts.com> Hi, I am using the yxa stack to provide Geolocations over SIP. I now have gotten a requirement that says that if the Geolocation ultimately will be sent to a contact using sips, I need to respond to the request using TLS/TCP, i.e. respons to a TCP request using TLS/TCP. The reason is amongst others to hide the location, if I understand the requirement correctly. Are there any support for this in the yxa stack? BR, Johan Vikman From fredrik at thulin.net Mon Sep 2 12:01:11 2013 From: fredrik at thulin.net (Fredrik Thulin) Date: Mon, 02 Sep 2013 12:01:11 +0200 Subject: [Yxa-devel] Changing transport to TLS/TCP In-Reply-To: <64A53ACC-AD14-4B2B-81DD-DFE702FAFD11@mobilearts.com> References: <64A53ACC-AD14-4B2B-81DD-DFE702FAFD11@mobilearts.com> Message-ID: <1378116071.15535.9.camel@xor> On Mon, 2013-09-02 at 11:20 +0200, Johan Vikman wrote: > Hi, > > I am using the yxa stack to provide Geolocations over SIP. > > I now have gotten a requirement that says that if the Geolocation ultimately will be sent to a contact using sips, I need to respond to the request using TLS/TCP, i.e. respons to a TCP request using TLS/TCP. > > The reason is amongst others to hide the location, if I understand the requirement correctly. > > Are there any support for this in the yxa stack? > Sorry, I don't really follow your use case. Can you show how the geolocation querying using SIP works in an example request/response flow? YXA supports SIPS with TLS over TCP, but I don't really understand your question I'm afraid. /Fredrik From johan.vikman at mobilearts.com Mon Sep 2 12:26:34 2013 From: johan.vikman at mobilearts.com (Johan Vikman) Date: Mon, 2 Sep 2013 12:26:34 +0200 Subject: [Yxa-devel] Changing transport to TLS/TCP In-Reply-To: <1378116071.15535.9.camel@xor> References: <64A53ACC-AD14-4B2B-81DD-DFE702FAFD11@mobilearts.com> <1378116071.15535.9.camel@xor> Message-ID: 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. /Johan On Sep 2, 2013, at 12:01 PM, Fredrik Thulin wrote: > On Mon, 2013-09-02 at 11:20 +0200, Johan Vikman wrote: >> Hi, >> >> I am using the yxa stack to provide Geolocations over SIP. >> >> I now have gotten a requirement that says that if the Geolocation ultimately will be sent to a contact using sips, I need to respond to the request using TLS/TCP, i.e. respons to a TCP request using TLS/TCP. >> >> The reason is amongst others to hide the location, if I understand the requirement correctly. >> >> Are there any support for this in the yxa stack? >> > > Sorry, I don't really follow your use case. Can you show how the > geolocation querying using SIP works in an example request/response > flow? > > YXA supports SIPS with TLS over TCP, but I don't really understand your > question I'm afraid. > > /Fredrik > > From fredrik at thulin.net Mon Sep 2 13:02:28 2013 From: fredrik at thulin.net (Fredrik Thulin) Date: Mon, 02 Sep 2013 13:02:28 +0200 Subject: [Yxa-devel] Changing transport to TLS/TCP In-Reply-To: References: <64A53ACC-AD14-4B2B-81DD-DFE702FAFD11@mobilearts.com> <1378116071.15535.9.camel@xor> Message-ID: <1378119748.15535.15.camel@xor> 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. 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 From johan.vikman at mobilearts.com Mon Sep 2 13:47:34 2013 From: johan.vikman at mobilearts.com (Johan Vikman) Date: Mon, 2 Sep 2013 13:47:34 +0200 Subject: [Yxa-devel] Changing transport to TLS/TCP In-Reply-To: <1378119748.15535.15.camel@xor> References: <64A53ACC-AD14-4B2B-81DD-DFE702FAFD11@mobilearts.com> <1378116071.15535.9.camel@xor> <1378119748.15535.15.camel@xor> Message-ID: <017C82A6-5352-48EF-981F-8F8A10AEFC8A@mobilearts.com> Hi Fredrik, See my response below. Thanks for your help! BR, Johan On Sep 2, 2013, at 1:02 PM, Fredrik Thulin 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: From fredrik at thulin.net Mon Sep 2 13:55:50 2013 From: fredrik at thulin.net (Fredrik Thulin) Date: Mon, 02 Sep 2013 13:55:50 +0200 Subject: [Yxa-devel] Changing transport to TLS/TCP In-Reply-To: <017C82A6-5352-48EF-981F-8F8A10AEFC8A@mobilearts.com> References: <64A53ACC-AD14-4B2B-81DD-DFE702FAFD11@mobilearts.com> <1378116071.15535.9.camel@xor> <1378119748.15535.15.camel@xor> <017C82A6-5352-48EF-981F-8F8A10AEFC8A@mobilearts.com> Message-ID: <1378122950.15535.27.camel@xor> On Mon, 2013-09-02 at 13:47 +0200, Johan Vikman wrote: ... > > > > 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. > Ok, well - that's just not how SIP works. The response is sent using the same transport as the request arrived on. The UAS can send back a redirect to get the UAC to re-submit it's request using TLS, but I bet you don't want to introduce latency in the 112 flow. You could have YXA proxy the request to the PSAP instead. Buys you some benefits, costs you some issues. /Fredrik From cloos+yxa at jhcloos.com Tue Sep 3 01:15:11 2013 From: cloos+yxa at jhcloos.com (James Cloos) Date: Mon, 02 Sep 2013 19:15:11 -0400 Subject: [Yxa-devel] Changing transport to TLS/TCP In-Reply-To: <017C82A6-5352-48EF-981F-8F8A10AEFC8A@mobilearts.com> (Johan Vikman's message of "Mon, 2 Sep 2013 13:47:34 +0200") References: <64A53ACC-AD14-4B2B-81DD-DFE702FAFD11@mobilearts.com> <1378116071.15535.9.camel@xor> <1378119748.15535.15.camel@xor> <017C82A6-5352-48EF-981F-8F8A10AEFC8A@mobilearts.com> Message-ID: >>>>> "JV" == Johan Vikman writes: JV> That was my guess to, but the product owner wants the transport to change in the 300 response. You will need to use two 300 replies. If LRF detects that the final leg will be a sips: uri and the incoming invite is not onver TLS, it needs to send a 300 pointing to its own sips: uri. When the LRF sees invites to its sips: uri, it can 300 those invite to their proper destinations. You need to know the requirements for the case where the initial invite is to your sips: and the final destination does not support sips. Ie, whether non-tls sip: uris are OK in the 300s. Put another way, whether it is OK to downgrade calls from UAs which seem to want encryption if the destination PSAPs do not support sips. Also, there is the case where the UA does not support sips. They won't be able to deal with the initial 300 to your sips: uri. Maybe that 300 can contain a different sip: uri which will not try to upgrade to sips: even when the destination supports that? If the uris in the 300 have a priority ordering, that might work. So, it looks like you would need a primary sips: uri, a primary sip: uri and a secondary sip: uri for the LRF. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From johan.vikman at mobilearts.com Tue Sep 3 17:08:44 2013 From: johan.vikman at mobilearts.com (Johan Vikman) Date: Tue, 03 Sep 2013 17:08:44 +0200 Subject: [Yxa-devel] Changing transport to TLS/TCP In-Reply-To: <1378122950.15535.27.camel@xor> References: <64A53ACC-AD14-4B2B-81DD-DFE702FAFD11@mobilearts.com> <1378116071.15535.9.camel@xor> <1378119748.15535.15.camel@xor> <017C82A6-5352-48EF-981F-8F8A10AEFC8A@mobilearts.com> <1378122950.15535.27.camel@xor> Message-ID: <5225FB7C.4000107@mobilearts.com> Hi again, How can I proxy the request to the PSAP? What do I need to return in the request function? /Johan > Ok, well - that's just not how SIP works. The response is sent using the > same transport as the request arrived on. > > The UAS can send back a redirect to get the UAC to re-submit it's > request using TLS, but I bet you don't want to introduce latency in the > 112 flow. > > You could have YXA proxy the request to the PSAP instead. Buys you some > benefits, costs you some issues. > > /Fredrik > > > From fredrik at thulin.net Tue Sep 3 18:23:20 2013 From: fredrik at thulin.net (Fredrik Thulin) Date: Tue, 03 Sep 2013 18:23:20 +0200 Subject: [Yxa-devel] Changing transport to TLS/TCP Message-ID: Well, there is documentation.? /Fredrik -------- Original message -------- From: Johan Vikman Date: To: Fredrik Thulin Cc: yxa-devel at lists.su.se Subject: Re: [Yxa-devel] Changing transport to TLS/TCP Hi again, How can I proxy the request to the PSAP? What do I need to return in the request function? /Johan > Ok, well - that's just not how SIP works. The response is sent using the > same transport as the request arrived on. > > The UAS can send back a redirect to get the UAC to re-submit it's > request using TLS, but I bet you don't want to introduce latency in the > 112 flow. > > You could have YXA proxy the request to the PSAP instead. Buys you some > benefits, costs you some issues. > > /Fredrik > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: