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 <[email protected]>: > 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 <[email protected]> > 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: [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]> > 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]> > To: "Kamailio (SER) - Users Mailing List" > <[email protected]> > Subject: Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher > Message-ID: > <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 ? > > 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]> > 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 > [email protected]https://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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
