<div dir="ltr">Hundred times I saw the scheme Figure 1 on <a href="https://tools.ietf.org/html/rfc3261#section-21.4.9" target="_blank">https://tools.ietf.org/html/<wbr>rfc3261#section-21.4.9</a>, but I have understood only now.<br>ACK is sent straight to provider, passing opensips and freeswitch, and he doesn't support tls.<br>But in that case, it turns out that neither opensips, nor freeswitch shouldn't know about ACK package anything at all. Nevertheless, when using udp only mode, I see such lines in opensips logs:<br><br><blockquote>DBG:tm:t_lookup_request: start searching: hash=40850, isACK=1<br> ...<br>DBG:core:forward_request: sending:#012ACK sip:*7906****@172.31.*.*:5060;<wbr>transport=udp SIP/2.0#015#012Via: SIP/2.0/UDP sip0.*.*:5060;branch=<wbr>z9hG4bK29f9.d0636cd7.2#015#<wbr>012Via: SIP/2.0/UDP 192.168.0.112:10075;received=<wbr>85.236.*.*;branch=z9hG4bK-<wbr>524287-1---253d1a7c9513df35;<wbr>rport=10075#015#012Max-<wbr>Forwards: 69#015#012Contact: <sip:8@85.236.*.*:10075>;+sip.<wbr>instance="<urn:uuid:BB208CA9-<wbr>1F2D-3364-B3AB-097FEF02C92E>"#<wbr>015#012To: <sip:*7906****@sip0.*.*>;tag=<wbr>6c41ctHDQg91H#015#012From: "8" <sip:8@sip0.*.*>;tag=33777e7a#<wbr>015#012Call-ID: K1D1nVCYhahISHcjIjNAPQ..#015#<wbr>012CSeq: 2 ACK#015#012User-Agent: PortSIP SDK for IOS#015#012Content-Length: 0#015#012#015#012.<br></blockquote><br><br>Also, according to this scheme BYE is sent similarly, directly from provider to a mobile application through udp when the mobile application is supported only by tls. In that case the mobile client shouldn't hang up when the client has finished a call after the provider, but the mobile client hang up - BYE reaches him. When the mobile client finishes a call - it works too, BYE reaches provider and the client after him.<br>Moreover, in such cases I see these BYE packages on opensips and freeswitch.<br><br>What is it, behavior not completely on RFC? Or I don't understand something?<br><br>Whether it could be because of the fact, that a call on 7906 **** is in fact a conference call - by this moment already 2 mobile applications carry on conversation through opensips?<div class="gmail_extra"><br><div class="gmail_quote">2016-08-19 10:31 GMT+03:00 Стас Тельнов <span dir="ltr"><<a href="mailto:stasan89@gmail.com" target="_blank">stasan89@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Yes, I've read this RFC.<br><br>In my case<span lang="en"><span><br></span></span><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span><span><div dir="ltr"><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">BYE sip:8@85.236.*.*:55194;ob;</span><font color="#ff0000"><span style="font-family:"helvetica neue",helvetica,arial,sans-serif">tran</span><span style="font-family:"helvetica neue",helvetica,arial,sans-serif"><wbr>sport=tls</span></font><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"> SIP/2.</span></div></div></span></span><span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">and</span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"></span><br><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"></span><div dir="ltr"><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">Contact: <sip:*7906******@52.58.*.*:506</span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><wbr>0;</span><span style="font-family:"helvetica neue",helvetica,arial,sans-serif"><font color="#ff0000">transport=udp</font></span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">></span><br></div></div></span></blockquote><span><div dir="ltr"><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"></span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><br>is not an error.<br>In my case Alice (8@85.236. *. *) uses tls, but Bob (*7906 ****** @52.58. *. *) uses udp.<br><br>I can configure Alice softphone, freeswitch and opensips. Alice <--> uses only tls.<br>I can not configure sip of provider and Bob's phone. Sip provider <--> Bob uses only udp.<br><br>I believe that such scheme is possible. If I send BYE packet for example from Alice softphone, then<br>1. This packet goes on opensips using tls<br>2. opensips changes the protocol for udp and sends a packet to freeswitch.<br>3. freeswitch sends a packet using udp to sip of provider and it sends it to Bob.<br><br>Similarly when Bob sends BYE packet:<br>1. freeswitch accepts udp packet from provider and sends it to opensisps using udp<br>2. opensisps accepts this udp packet, changes the protocol for tls and sends this packet to Alice using tls.<br><br>But with ACK packet between sip provider and freeswitch something goes wrong.<br></span></div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><br></span></div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"></span></div></div></span><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-18 18:38 GMT+03:00 Sergey Safarov <span dir="ltr"><<a href="mailto:s.safarov@gmail.com" target="_blank">s.safarov@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>It may be root of issue<span><div dir="ltr"><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">BYE sip:8@85.236.*.*:55194;ob;</span><font color="#ff0000"><span style="font-family:"helvetica neue",helvetica,arial,sans-serif">tran</span><span style="font-family:"helvetica neue",helvetica,arial,sans-serif"><wbr>sport=tls</span></font><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"> SIP/2.0</span><br></div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><br></span></div></div></span><div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">and<br></span></div></div><span><div dir="ltr"><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">Contact: <sip:*7906******@52.58.*.*:506</span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><wbr>0;</span><span style="font-family:"helvetica neue",helvetica,arial,sans-serif"><font color="#ff0000">transport=udp</font></span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">></span><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><br></span></div></div></span><div><div></div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><br></span></div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif">Look at </span><font face="helvetica neue, helvetica, arial, sans-serif" color="#212121"><a href="https://tools.ietf.org/html/rfc3261#section-4" target="_blank">https://tools.ietf.org/html<wbr>/rfc3261#section-4</a> </font><span style="font-size:13.3333px;line-height:normal">Figure 1: SIP session setup example with SIP trapezoid</span></div><div><span style="font-size:13.3333px;line-height:normal"><br></span></div><div><span style="font-size:13.3333px;line-height:normal">Sergey</span></div><div><span style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><br></span></div><div><br></div></div><br><div class="gmail_quote"><div>чт, 18 авг. 2016 г. в 18:28, Стас Тельнов <<a href="mailto:stasan89@gmail.com" target="_blank">stasan89@gmail.com</a>>:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div>I have freeswitch and opensips working with the mobile client in the conference mode.<br>When using UDP connection everything works perfectly, but when using tls connection the call is interrupted in 30 seconds.<br>Whether
to use TLS or UDP connection - it is assigned on the mobile client
before initialization of connection with opensips server.<br><br>Originally
I assumed that these problems were caused by the NAT settings, but in
that case the problem would be watched irrespective of the connection
used - UDP or TLS.<br><br>Generally such scheme works as it should:<br><br>+++++++++ udp ++++++++ udp +++++++++ udp +++++++++<br>+ + -----> + + -----> + + -----> + +<br>+ phone + + SIP + + free + + SIP +<br>+ + <----- + + <----- + switch + <----- + provider +<br>+++++++++ udp ++++++++ udp +++++++++ udp +++++++++<br><br>And in such scheme a call breaks in 30 seconds:<br><br>+++++++++ tls +++++++++ udp +++++++++ udp +++++++++<br>+ + -----> + + -----> + + -----> + +<br>+ phone + + SIP + + free + + SIP +<br>+ + <----- + + <----- + switch + <----- + provider +<br>+++++++++ tls +++++++++ udp +++++++++ udp +++++++++<br><br>SIP
and freeswitch are in one local area network (Amazon EC2). SIP provider
doesn't support tls in principle, they have 5061 closed.<br><br>And the
BYE packet sends freeswitch, as I understand, from packet headers as I
didn't receive the response to ACK in time. There is the packet:<br>BYE sip:8@85.236.*.*:55194;ob;tran<wbr>sport=tls SIP/2.0<br>Via: SIP/2.0/TLS sip0.*.*:5061;branch=z9hG4bKc7<wbr>a2.7909e7e1.0;received=52.58.*<wbr>.*<br>Via: SIP/2.0/UDP 172.31.*.*;received=52.58.*.*;<wbr>rport=5060;branch=z9hG4bKBK82Z<wbr>g50c2U0p<br>Max-Forwards: 69<br>Contact: <sip:*7906******@52.58.*.*:506<wbr>0;transport=udp><br>To: "8" <sip:8@sip0.*.*>;tag=59221e6a<br>From: <sip:*7906******@sip0.*.*>;tag<wbr>=j4aX21rv83etN<br>Call-ID: O7E3ktwLPiQWDN2Rism-7g..<br>CSeq: 95383912 BYE<br>Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY<br>Supported: timer, path, replaces<br>User-Agent: FreeSWITCH-mod_sofia/1.6.6~64b<wbr>it<br>Reason: SIP;cause=408;text="ACK Timeout"<br>Content-Length: 0<br><br>Having
looked on logs, I can tell that the INVITE packet from the mobile
client reach freeswitch and provider, but in reverse Trying/Ringing
packet doesn't reach.<br><br>I can't understand at what stage there is a
problem. Freeswitch can't respond and transmit the response through
opensips, or there is a problem in something else?<br>Who faced similar
problem, prompt what settings should be analyzed in order that the
above-stated scheme with tls connection start functionning?<div><br></div></div></div></div></div>
______________________________<wbr>______________________________<wbr>_____________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions<wbr>.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.o<wbr>rg</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswi<wbr>tch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/ma<wbr>ilman/listinfo/freeswitch-user<wbr>s</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.frees<wbr>witch.org/mailman/options/free<wbr>switch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a></blockquote></div></div>
<br>______________________________<wbr>______________________________<wbr>_____________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions<wbr>.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.o<wbr>rg</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswi<wbr>tch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/ma<wbr>ilman/listinfo/freeswitch-user<wbr>s</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.frees<wbr>witch.org/mailman/options/free<wbr>switch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>