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 >> <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> >>> To: "Kamailio (SER) - Users Mailing List" >>> <[email protected] <mailto:[email protected]>> >>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 >>> [email protected] >>> 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
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
