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

[Sergey Safarov]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160818/c9561497/attachment-0001.html