[SR-Users] Source Port on TLS OPTIONS from Dispatcher

[Charles Phillips]

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 <miconda at 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 <joel at textplus.com <mailto:joel at textplus.com>>
>> To: "Kamailio (SER) - Users Mailing List"
>> 	<sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>>
>> Subject: Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher
>> Message-ID:
>> 	<CAMtXxQnLtEyD=40cwKembxiyj3D778eK=+5JD7sL4CvYbYXF1g at mail.gmail.com <mailto:CAMtXxQnLtEyD=40cwKembxiyj3D778eK=+5JD7sL4CvYbYXF1g at 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 <charles at rustybike.com <mailto:charles at 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 at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210108/0f31031c/attachment.htm>