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
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 ?
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 Thu, Jan 7, 2021 at 4:32 PM Charles Phillips 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@textplus.com mailto:joel@textplus.com> To: "Kamailio (SER) - Users Mailing List" <sr-users@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@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@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
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@textplus.com mailto:joel@textplus.com> To: "Kamailio (SER) - Users Mailing List" <sr-users@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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@textplus.com mailto:joel@textplus.com> To: "Kamailio (SER) - Users Mailing List" <sr-users@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@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@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@lists.kamailio.org mailto:sr-users@lists.kamailio.org 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
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@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@textplus.com mailto:joel@textplus.com> To: "Kamailio (SER) - Users Mailing List" <sr-users@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@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@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@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
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: 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;tag=3393f0703fb0ccaca74109ff37de39f5-69555a28 TO: sip:sip3.pstnhub.microsoft.com CSEQ: 10 OPTIONS CALL-ID: 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
On Jan 11, 2021, at 4:13 AM, Daniel-Constantin Mierla 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
On Jan 8, 2021, at 12:56 PM, Daniel-Constantin Mierla <miconda@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@textplus.com mailto:joel@textplus.com> To: "Kamailio (SER) - Users Mailing List" <sr-users@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@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@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@lists.kamailio.org mailto:sr-users@lists.kamailio.org 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
It is my understanding that for outbound connections, subsequent transactions to the same destination IP:port reuse an existing TLS socket (if one exists) by design. By the logs, it appears that this matching takes place early in the processing so there is no regard for a new outbound transaction that has different SNI. Is this correct? Is there a way to force a new outbound TLS connection for a new transaction based on some other identifier?
- Charles Phillips
On Jan 11, 2021, at 9:00 AM, Charles Phillips charles@rustybike.com 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@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@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
On Jan 11, 2021, at 4:13 AM, Daniel-Constantin Mierla <miconda@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
On Jan 8, 2021, at 12:56 PM, Daniel-Constantin Mierla <miconda@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@textplus.com mailto:joel@textplus.com> To: "Kamailio (SER) - Users Mailing List" <sr-users@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@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@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@lists.kamailio.org mailto:sr-users@lists.kamailio.org 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
SIP transactions are decoupled from the transport layer, by specs, the connections have to be reused for the same target ip/port.
Cheers, Daniel
On 12.01.21 16:51, Charles Phillips wrote:
It is my understanding that for outbound connections, subsequent transactions to the same destination IP:port reuse an existing TLS socket (if one exists) by design. By the logs, it appears that this matching takes place early in the processing so there is no regard for a new outbound transaction that has different SNI. Is this correct? Is there a way to force a new outbound TLS connection for a new transaction based on some other identifier?
- Charles Phillips
On Jan 11, 2021, at 9:00 AM, Charles Phillips <charles@rustybike.com mailto:charles@rustybike.com> 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@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@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
On Jan 11, 2021, at 4:13 AM, Daniel-Constantin Mierla <miconda@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
On Jan 8, 2021, at 12:56 PM, Daniel-Constantin Mierla <miconda@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@textplus.com mailto:joel@textplus.com> To: "Kamailio (SER) - Users Mailing List" <sr-users@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@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@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@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
Hi All,
For TCP proto this is normal behaviour, originating from random port.
To work with TLS/TCP on client side you need set insecure=port for Asterisk (this just for example).
I have another issue, options in dialog(TCP/TLS) to check if dialog alive, they are sending from random port, but in my case dialog was established and call running. But when I have time I will make debug, tcp dump and open issue on tracker.
-- WBR Sergey Basov
ср, 13 янв. 2021 г., 16:29 Daniel-Constantin Mierla miconda@gmail.com:
SIP transactions are decoupled from the transport layer, by specs, the connections have to be reused for the same target ip/port.
Cheers, Daniel On 12.01.21 16:51, Charles Phillips wrote:
It is my understanding that for outbound connections, subsequent transactions to the same destination IP:port reuse an existing TLS socket (if one exists) by design. By the logs, it appears that this matching takes place early in the processing so there is no regard for a new outbound transaction that has different SNI. Is this correct? Is there a way to force a new outbound TLS connection for a new transaction based on some other identifier?
- Charles Phillips
On Jan 11, 2021, at 9:00 AM, Charles Phillips charles@rustybike.com 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") { $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: 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
;tag=3393f0703fb0ccaca74109ff37de39f5-69555a28
TO: sip:sip3.pstnhub.microsoft.com CSEQ: 10 OPTIONS CALL-ID: 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
On Jan 11, 2021, at 4:13 AM, Daniel-Constantin Mierla 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
On Jan 8, 2021, at 12:56 PM, Daniel-Constantin Mierla 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@textplus.com To: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Subject: Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher Message-ID: 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 ?
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@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 Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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
On Jan 11, 2021, at 4:13 AM, Daniel-Constantin Mierla <miconda@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
On Jan 8, 2021, at 12:56 PM, Daniel-Constantin Mierla <miconda@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@textplus.com mailto:joel@textplus.com> To: "Kamailio (SER) - Users Mailing List" <sr-users@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@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@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@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
-
Charles Phillips -
Daniel-Constantin Mierla -
Joel Serrano -
Sergey Basov