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

Reply via email to