It doesn't work to use t_relay() in event_route[tm:local-request] (and executed sub-routes), because it is already processing a relayed local request. That's why you get the error. Just set the $du and then exit, or set the outbound proxy attribute in the dispatcher record.
Also, setting the tls-related xavps does not have effect. Cheers, Daniel On 11.01.21 15:00, Charles Phillips 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