SIP transactions are decoupled from the transport layer, by specs, the connections have to be reused for the same target ip/port.
Cheers, Daniel On 12.01.21 16:51, Charles Phillips wrote: > It is my understanding that for outbound connections, subsequent > transactions to the same destination IP:port reuse an existing TLS > socket (if one exists) by design. By the logs, it appears that this > matching takes place early in the processing so there is no regard for > a new outbound transaction that has different SNI. Is this correct? > Is there a way to force a new outbound TLS connection for a new > transaction based on some other identifier? > > > - Charles Phillips > > > > >> On Jan 11, 2021, at 9:00 AM, Charles Phillips <char...@rustybike.com >> <mailto:char...@rustybike.com>> wrote: >> >> That is what I figured was happening. I have tried sending it back >> to a standard routing block, but perhaps I am doing it incorrectly. >> >> When I try to send it back to a regular routing block I get the >> following error: >> >> CRITICAL: tm [tm.c:1754]: _w_t_relay_to(): unsupported route type: 64 >> >> Config: >> >> event_route[tm:local-request] { >> sip_trace(); >> if(is_method("OPTIONS") && $ru =~ "pstnhub.microsoft.com >> <http://pstnhub.microsoft.com/>") { >> $var(domain) = $fd; >> append_hf("Contact: <sip:$var(domain):5061;transport=tls >> <sip:$var(domain):5061;transport=tls>>\r\n"); >> xlog("L_INFO", “TEAMS Contact: $var(domain)\r\n"); >> route(TEAMS_SEND); >> } >> xlog("L_INFO", "Sent out tm request: $mb\n"); >> } >> >> route[TEAMS_SEND] { >> $var(domain) = $fd; >> $xavp(tls=>server_name) = $var(domain); >> $xavp(tls[0]=>server_id) = $var(domain); >> $du = "sip:$var(domain):5061;transport=tls >> <sip:$var(domain):5061;transport=tls>"; >> t_relay(); >> } >> >> >> For testing, I also tried generating the packets in a normal route >> using t_uac_send and controlling it with rtimer. As ugly a hack that >> this approach is, it did manage to create the packets and set the >> xavp as required (although, it certainly wouldn’t help dispatcher >> know if a gateway is offline…). Additional trouble is that if a >> second domain attempts to send OPTIONS packets in the while loop (see >> below) it goes out the same TLS connection, so it is rejected. >> >> Config: >> >> route["PING-TEAMS"] { >> sql_query("db", "select domain from domain;", "domain_list"); >> $var(i) = 0; >> while ($dbr(domain_list=>[$var(i),0]) != $null) { >> $var(domain) = $dbr(domain_list=>[$var(i),0]); >> xlog(“OPTIONS from domain name $var(domain)"); >> $xavp(tls=>server_name) = $var(domain); >> $xavp(tls[0]=>server_id) = $var(domain); >> $du = "sip:$var(domain):5061;transport=tls >> <sip:$var(domain):5061;transport=tls>"; >> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls >> <sip:$var(domain):5061;transport=tls>", >> "sip:sip3.pstnhub.microsoft.com;transport=tls >> <sip:sip3.pstnhub.microsoft.com;transport=tls>", "", "From: >> sip:$var(domain) <sip:$var(domain)>\r\nTo: >> sip:sip3.pstnhub.microsoft.com;transport=tls >> <sip:sip3.pstnhub.microsoft.com;transport=tls>\r\nContact: >> <sip:$var(domain):5061;transport=tls >> <sip:$var(domain):5061;transport=tls>>\r\n", ""); >> sleep(2); >> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls >> <sip:$var(domain):5061;transport=tls>", >> "sip:sip2.pstnhub.microsoft.com;transport=tls >> <sip:sip2.pstnhub.microsoft.com;transport=tls>", "", "From: >> sip:$var(domain) <sip:$var(domain)>\r\nTo: >> sip:sip2.pstnhub.microsoft.com;transport=tls >> <sip:sip2.pstnhub.microsoft.com;transport=tls>\r\nContact: >> <sip:$var(domain):5061;transport=tls >> <sip:$var(domain):5061;transport=tls>>\r\n", ""); >> sleep(2); >> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls >> <sip:$var(domain):5061;transport=tls>", >> "sip:sip.pstnhub.microsoft.com;transport=tls >> <sip:sip.pstnhub.microsoft.com;transport=tls>", "", "From: >> sip:$var(domain) <sip:$var(domain)>\r\nTo: >> sip:sip.pstnhub.microsoft.com;transport=tls >> <sip:sip.pstnhub.microsoft.com;transport=tls>\r\nContact: >> <sip:$var(domain):5061;transport=tls >> <sip:$var(domain):5061;transport=tls>>\r\n", ""); >> sleep(5); >> $var(i) = $var(i) + 1; >> >> } >> } >> >> 200 from MS on domain 0: >> >> 2021/01/11 08:48:31.291048 52.114.7.24:5061 -> *myip*:52606 >> SIP/2.0 200 OK >> FROM: <sip:100.sbc.*mydomain*.net >> <sip:100.sbc.*mydomain*.net>>;tag=3393f0703fb0ccaca74109ff37de39f5-5a503a0a >> TO: <sip:sip3.pstnhub.microsoft.com <sip:sip3.pstnhub.microsoft.com>> >> CSEQ: 10 OPTIONS >> CALL-ID: 0f37a09f409a4e41-24410@127.0.0.1 >> <mailto:0f37a09f409a4e41-24410@127.0.0.1> >> VIA: SIP/2.0/TLS >> *myip*:5061;branch=z9hG4bK9306.42d92227000000000000000000000000.0 >> CONTENT-LENGTH: 0 >> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY >> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0 >> >> >> 403 from MS on domain 1: >> >> 2021/01/11 08:49:39.755005 52.114.7.24:5061 -> *myip*:52606 >> SIP/2.0 403 Forbidden >> FROM: <sip:101.sbc.*mydomain*.net >> <sip:101.sbc.*mydomain*.net>>;tag=3393f0703fb0ccaca74109ff37de39f5-69555a28 >> TO: <sip:sip3.pstnhub.microsoft.com <sip:sip3.pstnhub.microsoft.com>> >> CSEQ: 10 OPTIONS >> CALL-ID: 0f37a09f409a4e44-24410@127.0.0.1 >> <mailto:0f37a09f409a4e44-24410@127.0.0.1> >> VIA: SIP/2.0/TLS >> *myip*:5061;branch=z9hG4bK4306.973e1562000000000000000000000000.0 >> REASON: >> Q.850;cause=63;text="00cce062-66c6-45a4-8b5c-ccd48b71a9f6;Provided >> Trunk FQDN '101.sbc.*mydomain*.net' is not allowed. Connection allows >> ollowing fqdns: 100.sbc.*mydomain*.net, 100.sbc.*mydomain*.net." >> CONTENT-LENGTH: 0 >> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY >> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0 >> >> >> >> - Charles Phillips >> >> >> >> >>> On Jan 11, 2021, at 4:13 AM, Daniel-Constantin Mierla >>> <mico...@gmail.com <mailto:mico...@gmail.com>> wrote: >>> >>> Hello, >>> >>> the xavp_cfg set in the event_route is not propagated (kept) to the >>> moment when the message is sent out to tls. The >>> event_route[tm:local-request] is executed when the local request is >>> constructed, terminated before sending out, so whatever avp/xavp is >>> set in the event route are deleted when the block execution is >>> terminated. >>> >>> It requires another solution here, I am thinking about what can be >>> done and will be added soon in the master branch. >>> >>> Meanwhile, a workaround is to look traffic back to kamailio so the >>> routing happens over request_route block, where you can set the xavp. >>> >>> Cheers, >>> Daniel >>> >>> On 08.01.21 22:23, Charles Phillips wrote: >>>> Thanks Daniel, I needed some certainty to get unstuck. It appears >>>> that the problem is actually related to the TLS config. I am using >>>> multiple TLS configs, so it looks like the problem may be that the >>>> server_name server_id are not being set, so the reply is returning >>>> to the default TLS config. Not to mention that when I set the >>>> testing domains certs under the default config, it works... >>>> >>>> This is observed in the logs: >>>> >>>> tls_get_connect_server_name(): xavp with outbound server name not found >>>> tls_get_connect_server_id(): xavp with outbound server id not found >>>> tls_complete_init(): Using initial TLS domain TLSc<default> >>>> >>>> Is there a way to set this with xavp_cfg in the event_route? I >>>> have read that section and tried may combinations, but since the >>>> OPTIONs packets from the dispatcher module do not seem to traverse >>>> the standard routes, I am not sure how to handle this. >>>> >>>> Any advice would be greatly appreciated! >>>> >>>> >>>> - Charles Phillips >>>> >>>> >>>> >>>> >>>>> On Jan 8, 2021, at 12:56 PM, Daniel-Constantin Mierla >>>>> <mico...@gmail.com <mailto:mico...@gmail.com>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> there is an option that you can set to reuse the port for tcp/tls >>>>> connections, but even so it is a best effort and it is not going >>>>> to ensured -- all these are practically flags set to the sockets >>>>> and the kernel (tcp stack) decides after all. >>>>> >>>>> Anyhow, the rport is mainly useful for connectionless >>>>> communication, like UDP. For tcp/tls, the SIP specs demand to >>>>> reuse the existing connections. As I did several Kamailio-MSTeams >>>>> interconnectivity deployments, I can tell that the source port was >>>>> never a problem. The TLS connection is kept open and MSTeams sends >>>>> back traffic on it. >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> On 08.01.21 14:32, Charles Phillips wrote: >>>>>> Thanks for the quick response Joel. Yes, I have read the article >>>>>> and I have tested and confirmed that I am correctly appending the >>>>>> contact header (I probably should have left that in the snippet >>>>>> for clarity). Below is an example of Kamailio setting up the >>>>>> connection. It is going out port 46245 this time, but it is random. >>>>>> >>>>>> 07:59:23.572319 IP *my.kamailio.server*.46245 > >>>>>> *ms.teams.server*.sip-tls: Flags [P.], seq 1:518, ack 1, win 502, >>>>>> length 517 >>>>>> 07:59:23.802458 IP *ms.teams.server*.sip-tls > >>>>>> *my.kamailio.server*.46245: Flags [P.], seq 1:3767, ack 518, win >>>>>> 2051, length 3766 >>>>>> >>>>>> The TLS connection shows as successful in the logs. >>>>>> >>>>>> >>>>>> - Charles >>>>>> >>>>>> >>>>>> Date: Thu, 7 Jan 2021 19:12:10 -0800 >>>>>> From: Joel Serrano <j...@textplus.com <mailto:j...@textplus.com>> >>>>>> To: "Kamailio (SER) - Users Mailing List" >>>>>> <sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>> >>>>>> Subject: Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher >>>>>> Message-ID: >>>>>> <CAMtXxQnLtEyD=40cwKembxiyj3D778eK=+5jd7sl4cvybyx...@mail.gmail.com >>>>>> <mailto:CAMtXxQnLtEyD=40cwKembxiyj3D778eK=+5jd7sl4cvybyx...@mail.gmail.com>> >>>>>> Content-Type: text/plain; charset="utf-8" >>>>>> >>>>>> Hi Charles, >>>>>> >>>>>> I don't think your issue is rport, make sure you are setting the >>>>>> Contact >>>>>> header correctly. >>>>>> >>>>>> Have you checked this blog post: >>>>>> https://skalatan.de/en/blog/kamailio-sbc-teams >>>>>> <https://skalatan.de/en/blog/kamailio-sbc-teams> ? >>>>>> >>>>>> There is a specific section that talks about how to tell Kamailio >>>>>> to send >>>>>> the OPTIONS like MS Teams wants them. >>>>>> >>>>>> Good luck, >>>>>> Joel. >>>>>> >>>>>> >>>>>>> On Jan 7, 2021, at 7:31 PM, Charles Phillips >>>>>>> <char...@rustybike.com <mailto:char...@rustybike.com>> wrote: >>>>>>> >>>>>>> Hello all. As they say in radio, “long time listener, first >>>>>>> time caller” >>>>>>> >>>>>>> Anyway, I am having trouble getting past the following road >>>>>>> block and any help would be greatly appreciated. >>>>>>> >>>>>>> Kamailio version is 5.4.3 >>>>>>> >>>>>>> When attempting to use dispatcher to send OPTIONS packets to >>>>>>> several TLS destinations, the packets are leaving the Kamailio >>>>>>> server on random ports. This is a problem because the servers I >>>>>>> am sending the OPTIONS to (MS Teams) are enforcing rport so the >>>>>>> responses are returned to a port that Kamailio is not listening >>>>>>> on. I have tried to force the socket in the event route >>>>>>> (relevant parts of snippet below) but it does not appear to >>>>>>> help. I should also mention that I am not behind NAT and the >>>>>>> TLS socket is specified in the dispatcher attrs. >>>>>>> >>>>>>> event_route[tm:local-request] { >>>>>>> sip_trace(); >>>>>>> >>>>>>> >>>>>>> $fs = “tls:**ip-address**:5061”; >>>>>>> >>>>>>> >>>>>>> } >>>>>>> >>>>>>> I have used Kamailio as a TLS server for many projects, but this >>>>>>> is my first time as a client. I am sure I am missing something. >>>>>>> >>>>>>> - Charles >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Kamailio (SER) - Users Mailing List >>>>>> sr-users@lists.kamailio.org >>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>> -- >>>>> Daniel-Constantin Mierla -- www.asipto.com >>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda >>>>> Funding: https://www.paypal.me/dcmierla >>>> >>> -- >>> Daniel-Constantin Mierla -- www.asipto.com >>> www.twitter.com/miconda -- www.linkedin.com/in/miconda >>> Funding: https://www.paypal.me/dcmierla >> > -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users