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") {
$var(domain) = $fd;
append_hf("Contact: <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";
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";
t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls",
"sip:sip3.pstnhub.microsoft.com;transport=tls", "", "From:
sip:$var(domain)\r\nTo:
sip:sip3.pstnhub.microsoft.com;transport=tls\r\nContact:
<sip:$var(domain):5061;transport=tls>\r\n", "");
sleep(2);
t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls",
"sip:sip2.pstnhub.microsoft.com;transport=tls", "", "From:
sip:$var(domain)\r\nTo:
sip:sip2.pstnhub.microsoft.com;transport=tls\r\nContact:
<sip:$var(domain):5061;transport=tls>\r\n", "");
sleep(2);
t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls",
"sip:sip.pstnhub.microsoft.com;transport=tls", "", "From:
sip:$var(domain)\r\nTo: sip:sip.pstnhub.microsoft.com;transport=tls\r\nContact:
<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>;tag=3393f0703fb0ccaca74109ff37de39f5-5a503a0a
TO: <sip:sip3.pstnhub.microsoft.com>
CSEQ: 10 OPTIONS
CALL-ID: [email protected]
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>;tag=3393f0703fb0ccaca74109ff37de39f5-69555a28
TO: <sip:sip3.pstnhub.microsoft.com>
CSEQ: 10 OPTIONS
CALL-ID: [email protected]
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 <[email protected]>
> 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 <[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] <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>
> --
> 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
