[Freeswitch-users] Configure freeswitch and opensips for using tls and udp protocols simultaneously.
Стас Тельнов
stasan89 at gmail.com
Fri Aug 19 17:36:14 MSD 2016
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 at 85.236.
*.*:10075>;+sip.instance="<urn:uuid:BB208CA9-1F2D-3364-B3AB-097FEF02C92E>"#015#012To:
<sip:*7906****@sip0.*.*>;tag=6c41ctHDQg91H#015#012From: "8" <sip:8 at 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 at gmail.com>:
> 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=z9hG4bKc7
>>> a2.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/56204881/attachment-0001.html
Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users
mailing list