[SR-Users] Source Port on TLS OPTIONS from Dispatcher
Daniel-Constantin Mierla
miconda at gmail.com
Wed Jan 13 15:16:02 CET 2021
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 at 127.0.0.1
> <mailto:0f37a09f409a4e41-24410 at 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 at 127.0.0.1
> <mailto:0f37a09f409a4e44-24410 at 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
>> <miconda at gmail.com <mailto:miconda at 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
>>>> <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
>
--
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/20210113/c137ca8a/attachment.htm>
More information about the sr-users
mailing list