[Freeswitch-users] Configure freeswitch and opensips for using tls and udp protocols simultaneously.

[Стас Тельнов]

Yes, I've read this RFC.

In my case

BYE sip:8 at 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 at 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 at gmail.com>:

> It may be root of issue
> BYE sip:8 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160819/f352787d/attachment-0001.html