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

Mon Jan 11 10:13:54 CET 2021

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
>> <miconda at gmail.com <mailto: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
>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210111/05925ef6/attachment.htm>