13 Jan
2021
13 Jan
'21
9:16 a.m.
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(a)127.0.0.1
<mailto:0f37a09f409a4e41-24410@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(a)127.0.0.1
<mailto:0f37a09f409a4e44-24410@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
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
On Jan 11, 2021, at 4:13 AM, Daniel-Constantin
Mierla
<miconda(a)gmail.com <mailto:miconda@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
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla On Jan 8, 2021, at 12:56 PM, Daniel-Constantin
Mierla
<miconda(a)gmail.com <mailto:miconda@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(a)textplus.com <mailto:joel@textplus.com>>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
> Subject: Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher
> Message-ID:
> <CAMtXxQnLtEyD=40cwKembxiyj3D778eK=+5JD7sL4CvYbYXF1g(a)mail.gmail.com
>
<mailto:CAMtXxQnLtEyD=40cwKembxiyj3D778eK=+5JD7sL4CvYbYXF1g@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(a)rustybike.com <mailto:charles@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(a)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