Hundred times I saw the scheme Figure 1 on https://tools.ietf.org/html/rfc3261#section-21.4.9, but I have understood only now.
ACK is sent straight to provider, passing opensips and freeswitch, and he doesn't support tls.
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:

DBG:tm:t_lookup_request: start searching: hash=40850, isACK=1
 ...
DBG:core:forward_request: sending:#012ACK sip:*7906****@172.31.*.*:5060;transport=udp SIP/2.0#015#012Via: SIP/2.0/UDP sip0.*.*:5060;branch=z9hG4bK29f9.d0636cd7.2#015#012Via: SIP/2.0/UDP 192.168.0.112:10075;received=85.236.*.*;branch=z9hG4bK-524287-1---253d1a7c9513df35;rport=10075#015#012Max-Forwards: 69#015#012Contact: <sip:8@85.236.*.*:10075>;+sip.instance="<urn:uuid:BB208CA9-1F2D-3364-B3AB-097FEF02C92E>"#015#012To: <sip:*7906****@sip0.*.*>;tag=6c41ctHDQg91H#015#012From: "8" <sip:8@sip0.*.*>;tag=33777e7a#015#012Call-ID: K1D1nVCYhahISHcjIjNAPQ..#015#012CSeq: 2 ACK#015#012User-Agent: PortSIP SDK for IOS#015#012Content-Length: 0#015#012#015#012.


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.
Moreover, in such cases I see these BYE packages on opensips and freeswitch.

What is it, behavior not completely on RFC? Or I don't understand something?

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?

2016-08-19 10:31 GMT+03:00 Стас Тельнов <stasan89@gmail.com>:
Yes, I've read this RFC.

In my case

BYE sip:8@85.236.*.*:55194;ob;transport=tls SIP/2.
and
Contact: <sip:*7906******@52.58.*.*:5060;transport=udp>

is not an error.
In my case Alice (8@85.236. *. *) uses tls, but Bob (*7906 ****** @52.58. *. *) uses udp.

I can configure Alice softphone, freeswitch and opensips. Alice <--> uses only tls.
I can not configure sip of provider and Bob's phone. Sip provider <--> Bob uses only udp.

I believe that such scheme is possible. If I send BYE packet for example from Alice softphone, then
1. This packet goes on opensips using tls
2. opensips changes the protocol for udp and sends a packet to freeswitch.
3. freeswitch sends a packet using udp to sip of provider and it sends it to Bob.

Similarly when Bob sends BYE packet:
1. freeswitch accepts udp packet from provider and sends it to opensisps using udp
2. opensisps accepts this udp packet, changes the protocol for tls and sends this packet to Alice using tls.

But with ACK packet between sip provider and freeswitch something goes wrong.


2016-08-18 18:38 GMT+03:00 Sergey Safarov <s.safarov@gmail.com>:
It may be root of issue
BYE sip:8@85.236.*.*:55194;ob;transport=tls SIP/2.0

and
Contact: <sip:*7906******@52.58.*.*:5060;transport=udp>

Look at https://tools.ietf.org/html/rfc3261#section-4 Figure 1: SIP session setup example with SIP trapezoid

Sergey



чт, 18 авг. 2016 г. в 18:28, Стас Тельнов <stasan89@gmail.com>:
I have freeswitch and opensips working with the mobile client in the conference mode.
When using UDP connection everything works perfectly, but when using tls connection the call is interrupted in 30 seconds.
Whether to use TLS or UDP connection - it is assigned on the mobile client before initialization of connection with opensips server.

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.

Generally such scheme works as it should:

+++++++++   udp   ++++++++   udp   +++++++++   udp   +++++++++
+               + ----->  +              +  ----->  +               + ----->  +               +
+   phone  +           +   SIP     +             +    free    +           +     SIP    +
+               + <-----  +              +  <-----  +   switch  + <-----  + provider +
+++++++++   udp   ++++++++   udp    +++++++++   udp   +++++++++

And in such scheme a call breaks in 30 seconds:

+++++++++   tls   +++++++++   udp   +++++++++   udp   +++++++++
+               + ----->  +               +  ----->  +               + ----->  +               +
+   phone  +           +   SIP      +             +    free    +           +     SIP    +
+               + <-----  +               +  <-----  +   switch  + <-----  + provider +
+++++++++   tls   +++++++++   udp    +++++++++   udp   +++++++++

SIP and freeswitch are in one local area network (Amazon EC2). SIP provider doesn't support tls in principle, they have 5061 closed.

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:
BYE sip:8@85.236.*.*:55194;ob;transport=tls SIP/2.0
Via: SIP/2.0/TLS sip0.*.*:5061;branch=z9hG4bKc7a2.7909e7e1.0;received=52.58.*.*
Via: SIP/2.0/UDP 172.31.*.*;received=52.58.*.*;rport=5060;branch=z9hG4bKBK82Zg50c2U0p
Max-Forwards: 69
Contact: <sip:*7906******@52.58.*.*:5060;transport=udp>
To: "8" <sip:8@sip0.*.*>;tag=59221e6a
From: <sip:*7906******@sip0.*.*>;tag=j4aX21rv83etN
Call-ID: O7E3ktwLPiQWDN2Rism-7g..
CSeq: 95383912 BYE
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
User-Agent: FreeSWITCH-mod_sofia/1.6.6~64bit
Reason: SIP;cause=408;text="ACK Timeout"
Content-Length: 0

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.

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?
Who faced similar problem, prompt what settings should be analyzed in order that the above-stated scheme with tls connection start functionning?

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org