[Freeswitch-users] Getting FreeSWITCH to use RTP port + 1 for RTCP
James Mortensen
james.mortensen at synclio.com
Wed Dec 4 01:48:51 MSK 2013
> It has nothing to do with the SIP TLS settings.
I don't get what does it have to do with WSS settings? This is an Android
client connecting through UDP/TCP ports 5060/5070. It doesn't connect SIP
over WebSockets, hence my confusion.
Thanks,
James
On Tue, Dec 3, 2013 at 1:59 PM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:
> It has nothing to do with the SIP TLS settings.
> I believe I already listed what you need to make it work.
> You may want to start over with the default configs, place the files in
> the correct place and add the one binding for wss.
>
>
>
>
>
>
> On Tue, Dec 3, 2013 at 11:58 AM, James Mortensen <
> james.mortensen at synclio.com> wrote:
>
>> Hello,
>>
>> We followed the steps in this document to set up TLS:
>> http://wiki.freeswitch.org/wiki/SIP_TLS#If_your_SIP_profile_fails_to_start_upand followed these troubleshooting instructions. We have the certs in
>> ${prefix}/conf/ssl
>>
>> oot at ip-10-188-136-13:/opt/freeswitch-dev/conf/ssl# l
>> total 12
>> -rw-r----- 1 root root 579 Dec 3 10:27 cafile.pem
>> drwxr-x--- 2 root root 4096 Dec 3 10:28 CA
>> -rw-r----- 1 root root 999 Dec 3 10:28 agent.pem
>>
>> Also, I've verfied that libssl-dev is indeed installed, version 1.0.1.
>>
>>
>> When we try to load (or reload) the internal profile with the wss-binding
>> parameter enabled for port 7066, we see the following output:
>>
>> nta.c:2389 agent_init_via() nta: agent_init_via: SIP/2.0/udp
>> 50.18.X.X:5080 (sip)
>> nta.c:2389 agent_init_via() nta: agent_init_via: SIP/2.0/tcp
>> 50.18.X.X:5080 (sip)
>> nta.c:2389 agent_init_via() nta: agent_init_via: SIP/2.0/ws
>> 10.188.136.13:5066 (sip)
>> nta.c:2255 nta_agent_add_tport() nta: Via fields initialized
>> nta.c:2263 nta_agent_add_tport() nta: Contact header created
>> tport.c:1620 tport_bind_server() tport_bind_server(0x7fbf9c003ca0) to wss/
>> 10.188.136.13:7443/sips
>> tport.c:1690 tport_bind_server() tport_bind_server(0x7fbf9c003ca0):
>> calling tport_listen for wss
>> nua.c:575 nua_set_params() nua: nua_set_params: entering
>> tport.c:628 tport_alloc_primary() tport_alloc_primary(0x7fbf9c003ca0):
>> new primary tport 0x7fbf9c005e80
>> nua_stack.c:529 nua_signal() nua((nil)): sent signal r_set_params
>> nua_params.c:480 nua_stack_set_params() nua: nua_stack_set_params:
>> entering
>> soa.c:405 soa_set_params() soa_set_params(static::0x7fbfa8001ca0, ...)
>> called
>> tport.c:734 tport_listen() tport_listen(0x7fbf9c003ca0): unknown(pf=2
>> wss/[10.188.136.13]:7443): No such file or directory
>> nta.c:2237 nta_agent_add_tport() nta: bind(10.188.136.13:7443;transport=wss):
>> No such file or directory
>> nua_stack.c:195 nua_stack_init() nua: initializing SIP stack failed
>> nua_stack.c:212 nua_stack_deinit() nua: nua_stack_deinit: entering
>> sresolv.c:190 sres_sofia_update() sres_sofia_update(0x7fbf9c0038a0, -1,
>> -1)
>> sresolv.c:190 sres_sofia_update() sres_sofia_update((nil), -1, -1)
>> tport.c:562 tport_destroy() tport_destroy(0x7fbf9c003ca0)
>> su_epoll_port.c:166 su_epoll_port_deinit()
>> su_epoll_port_deinit(0x7fbf9c0008c0) called
>> 2013-12-03 17:47:36.815063 [ERR] sofia.c:2545 Error Creating SIP UA for
>> profile: internal (sip:mod_sofia at 50.18.X.X
>> :5080;maddr=10.188.136.13;transport=udp,tcp)
>> The likely causes for this are:
>> 1) Another application is already listening on the specified address.
>> 2) The IP the profile is attempting to bind to is not local to this
>> system.
>>
>>
>> And when trying to reload the profile, this is what we're seeing:
>>
>> freeswitch at ip-10-188-136-13> sofia profile internal restart
>>
>> Invalid Profile [internal]
>> freeswitch at ip-10-188-136-13>
>>
>>
>>
>> I'm a little unclear as to whether or not any certs actually need to be
>> installed on Android. The webrtc.freeswitch.org demo seems to work
>> without needing to do anything on the client side. What's more, that
>> shouldn't have any effect on the server's ability to start the profile.
>> What are we missing here? Thank you!
>>
>>
>>
>> James
>>
>>
>> On Wed, Nov 27, 2013 at 10:14 PM, Anthony Minessale <
>> anthony.minessale at gmail.com> wrote:
>>
>>> *HINT* you need to use a valid cert for the dtls and the ssl websocket
>>> Android is 100 times more paranoid about certs and doesn't bother to
>>> explain.
>>> A common theme in google code for webrtc to not take the time and effort
>>> to explain errors.
>>>
>>> go to /usr/local/freeswitch/certs
>>> put both the key and the cert in wss.pem
>>> put the same key in dtls-srtp.key and the same cert in dtls-srtp.crt
>>> put a valid chain cert in ca-bundle.crt
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Nov 27, 2013 at 7:09 PM, James Mortensen <
>>> james.mortensen at synclio.com> wrote:
>>>
>>>> I have limited information at this time, but we're basically seeing RTP
>>>> packets flowing from Chrome to FreeSWITCH and from FreeSWITCH to Chrome,
>>>> but very minimal activity between Android and FreeSWITCH.
>>>>
>>>> Before my colleague hit the road for the day, we did notice there were
>>>> two separate INVITES being sent to Android, and that's where we stopped.
>>>> It is possible there's a port mismatch somewhere, assuming we really did
>>>> see two INVITES in the FreeSWITCH SIP trace. To be sure, we registered
>>>> Chrome and Android on different networks so there was absolutely no
>>>> confusion.
>>>>
>>>> I've attached a SIP trace from several of these call attempts. Just
>>>> look from the top where you see a JsSIP client send an INVITE from
>>>> 50.43.x.x and then scroll down to see FreeSWITCH send two INVITES to two
>>>> separate ports on the 115.11.x.x network. Moreover, the candidates in both
>>>> INVITES contain different ports. Here are those two INVITES inline, where
>>>> user 1000 is the Android client on 115.11.x.x and 1100 is the Chrome JsSIP
>>>> client at 50.43.x.x, JsSIP initiates the call:
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> send 2031 bytes to udp/[115.11.X.X]:9322 at 23:25:08.408616:
>>>>
>>>> ------------------------------------------------------------------------
>>>> INVITE sip:1000 at 115.11.X.X:9322;transport=udp SIP/2.0
>>>> Via: SIP/2.0/UDP 50.18.X.X:5070;rport;branch=z9hG4bKrv59pQQvDaagc
>>>> Route: <sip:1000 at 115.11.X.X:9322;transpo;lr;ovid=c5ab5428>
>>>> Max-Forwards: 68
>>>> From: "James" <sip:971200xxxx at 10.188.136.13>;tag=UX0748rrX2Bgm
>>>> To: <sip:1000 at 115.11.X.X:9322;transport=udp>
>>>> Call-ID: fed8b6a7-d25d-1231-2cad-22000abc880d
>>>> CSeq: 52461290 INVITE
>>>> Contact: <sip:mod_sofia at 50.18.X.X:5070>
>>>> User-Agent:
>>>> FreeSWITCH-mod_sofia/1.5.8b+git~20131127T162035Z~bbe1fe1a31~64bit
>>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
>>>> REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
>>>> Supported: precondition, path, replaces
>>>> Allow-Events: talk, hold, conference, presence, as-feature-event,
>>>> dialog, line-seize, call-info, sla, include-session-description,
>>>> presence.winfo, message-summary, refer
>>>> Content-Type: application/sdp
>>>> Content-Disposition: session
>>>> Content-Length: 975
>>>> X-FS-Support: update_display,send_info
>>>> Remote-Party-ID: "James" <sip:971200xxxx at 10.188.136.13
>>>> >;party=calling;screen=yes;privacy=off
>>>>
>>>> v=0
>>>> o=FreeSWITCH 1385562204 1385562205 IN IP4 50.18.X.X
>>>> s=FreeSWITCH
>>>> c=IN IP4 50.18.X.X
>>>> t=0 0
>>>> a=sendrecv
>>>> a=msid-semantic: WMS oXSGoBbKflmyggzbJEZP120R0qAOBfsQ
>>>> m=audio 32504 RTP/SAVPF 0 8 101 13
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:101 telephone-event/8000
>>>> a=fingerprint:sha-256
>>>> 91:9E:50:FA:2E:A5:8E:02:41:1E:FC:A5:8A:B0:0C:1F:98:1F:1B:49:BB:D6:44:A8:E1:01:EA:82:7C:B6:59:1D
>>>> a=rtcp-mux
>>>> a=rtcp:32504 IN IP4 50.18.X.X
>>>> a=ssrc:177794596 cname:2bmhDoRIz36GawIJ
>>>> a=ssrc:177794596 msid:oXSGoBbKflmyggzbJEZP120R0qAOBfsQ a0
>>>> a=ssrc:177794596 mslabel:oXSGoBbKflmyggzbJEZP120R0qAOBfsQ
>>>> a=ssrc:177794596 label:oXSGoBbKflmyggzbJEZP120R0qAOBfsQa0
>>>> a=ice-ufrag:1xoTpfAgv0VX5dDX
>>>> a=ice-pwd:eQ5I4MguGd1GAzfr
>>>> a=candidate:5290007956 1 udp 659136 50.18.X.X 32504 typ host
>>>> generation 0
>>>> a=candidate:5290007956 2 udp 659136 50.18.X.X 32504 typ host
>>>> generation 0
>>>> a=crypto:1 AES_CM_128_HMAC_SHA1_80
>>>> inline:TTl8L9nzxRRf4R3jWWukpQaOSmkB5tncyLIuwvaA
>>>> a=ptime:20
>>>>
>>>> ------------------------------------------------------------------------
>>>> send 2034 bytes to udp/[115.11.X.X]:62163 at 23:25:08.409283:
>>>>
>>>> ------------------------------------------------------------------------
>>>> INVITE sip:1000 at 115.11.X.X:62163;transport=udp SIP/2.0
>>>> Via: SIP/2.0/UDP 50.18.X.X:5070;rport;branch=z9hG4bKS5y2rj8ZaK02Q
>>>> Route: <sip:1000 at 115.11.X.X:62163;transpo;lr;ovid=c5ab5428>
>>>> Max-Forwards: 68
>>>> From: "James" <sip:971200xxxx at 10.188.136.13>;tag=v6S0639UtB22F
>>>> To: <sip:1000 at 115.11.X.X:62163;transport=udp>
>>>> Call-ID: fed8d029-d25d-1231-2cad-22000abc880d
>>>> CSeq: 52461290 INVITE
>>>> Contact: <sip:mod_sofia at 50.18.X.X:5070>
>>>> User-Agent:
>>>> FreeSWITCH-mod_sofia/1.5.8b+git~20131127T162035Z~bbe1fe1a31~64bit
>>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
>>>> REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
>>>> Supported: precondition, path, replaces
>>>> Allow-Events: talk, hold, conference, presence, as-feature-event,
>>>> dialog, line-seize, call-info, sla, include-session-description,
>>>> presence.winfo, message-summary, refer
>>>> Content-Type: application/sdp
>>>> Content-Disposition: session
>>>> Content-Length: 975
>>>> X-FS-Support: update_display,send_info
>>>> Remote-Party-ID: "James" <sip:971200xxxx at 10.188.136.13
>>>> >;party=calling;screen=yes;privacy=off
>>>>
>>>> v=0
>>>> o=FreeSWITCH 1385569930 1385569931 IN IP4 50.18.X.X
>>>> s=FreeSWITCH
>>>> c=IN IP4 50.18.X.X
>>>> t=0 0
>>>> a=sendrecv
>>>> a=msid-semantic: WMS YGqq3KBdA3doGvggsuWTkskoGwvg99oY
>>>> m=audio 24778 RTP/SAVPF 0 8 101 13
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:101 telephone-event/8000
>>>> a=fingerprint:sha-256
>>>> 91:9E:50:FA:2E:A5:8E:02:41:1E:FC:A5:8A:B0:0C:1F:98:1F:1B:49:BB:D6:44:A8:E1:01:EA:82:7C:B6:59:1D
>>>> a=rtcp-mux
>>>> a=rtcp:24778 IN IP4 50.18.X.X
>>>> a=ssrc:177896132 cname:FFeyfGCFzFU610ck
>>>> a=ssrc:177896132 msid:YGqq3KBdA3doGvggsuWTkskoGwvg99oY a0
>>>> a=ssrc:177896132 mslabel:YGqq3KBdA3doGvggsuWTkskoGwvg99oY
>>>> a=ssrc:177896132 label:YGqq3KBdA3doGvggsuWTkskoGwvg99oYa0
>>>> a=ice-ufrag:lZ3vhdKOA6UA59oA
>>>> a=ice-pwd:EtZJZsepYZmPPpZ1
>>>> a=candidate:6658001960 1 udp 659136 50.18.X.X 24778 typ host
>>>> generation 0
>>>> a=candidate:6658001960 2 udp 659136 50.18.X.X 24778 typ host
>>>> generation 0
>>>> a=crypto:1 AES_CM_128_HMAC_SHA1_80
>>>> inline:CKFCzTuq04VQ1E0QJMmo0WjXDUtp+GTuK4CLgAS7
>>>> a=ptime:20
>>>>
>>>>
>>>> It seems like something is amiss here. This does seem odd. Hope this
>>>> helps!
>>>>
>>>>
>>>> James
>>>>
>>>>
>>>> On Wed, Nov 27, 2013 at 4:44 PM, Michael Jerris <mike at jerris.com>wrote:
>>>>
>>>>> Try looking at a pcap and comparing to the android logs. Are they
>>>>> sending the stun requests to the right place and are they getting to
>>>>> freeswitch?
>>>>>
>>>>> On Nov 27, 2013, at 7:38 PM, James Mortensen <
>>>>> james.mortensen at synclio.com> wrote:
>>>>>
>>>>> The issue is that Android is showing STUN ping timeouts in the
>>>>> libjingle logs. This doesn't happen with Asterisk, so we just asked
>>>>> ourselves, "What is different in the SDP's" and we noticed it's the way
>>>>> RTCP is handled....
>>>>>
>>>>> Now, I'm not suggesting using the port +1 method would solve the
>>>>> problem; it was mostly just something we thought to try to see if we'd get
>>>>> different results. If it's not worth trying, we'll try something else. :)
>>>>>
>>>>> I don't have the Android debug logs handy at this time, but we'll work
>>>>> on putting them together.
>>>>>
>>>>> Thanks!
>>>>> James
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 27, 2013 at 4:14 PM, Michael Jerris <mike at jerris.com>wrote:
>>>>>
>>>>>> We are using rtcp mux where it uses the same port. This is the
>>>>>> default for webrtc and I don't think we have a way to disable it for
>>>>>> outbound invites for webrtc media, but there shouldn't ever be a reason to
>>>>>> disable it as all the browsers support it and its required by the spec. As
>>>>>> for why its not working with chrome for android, I'm not sure, do you have
>>>>>> a debug log of the call?
>>>>>>
>>>>>>
>>>>>> On Nov 27, 2013, at 5:56 PM, James Mortensen <
>>>>>> james.mortensen at synclio.com> wrote:
>>>>>>
>>>>>> > Hello,
>>>>>> >
>>>>>> > I've searched the list and documentation, and it's not yet clear if
>>>>>> FreeSWITCH is able to send candidates in the same manner as we were doing
>>>>>> with Asterisk 1.5 where it sends the RTCP to the RTP port +1. In other
>>>>>> words, I'd see candidates that looked like this:
>>>>>> >
>>>>>> > a=candidate:3441596188 1 udp 659136 10.3.1.1 20622 typ host
>>>>>> generation 0
>>>>>> > a=candidate:3441596188 1 udp 659136 50.18.X.X 20622 typ srflx
>>>>>> generation 0
>>>>>> > a=candidate:3441596188 2 udp 659136 10.3.1.1 20623 typ host
>>>>>> generation 0
>>>>>> > a=candidate:3441596188 2 udp 659136 50.18.X.X 20623 typ srflx
>>>>>> generation 0
>>>>>> >
>>>>>> > For instance, if the RTP port was 20622, the RTCP port would be
>>>>>> 20623. We're getting no audio when trying to make Chrome to Android and
>>>>>> Android to Android WebRTC calls, and we thought we'd try a different RTCP
>>>>>> method as we did have it working with Asterisk but want to use FreeSWITCH
>>>>>> instead.
>>>>>> >
>>>>>> > I've checked out the latest FreeSWITCH code from the master branch.
>>>>>> >
>>>>>> > Not sure if FreeSWITCH can do this yet, but if anyone knows that
>>>>>> would be helpful.
>>>>>> >
>>>>>> > Thank you!
>>>>>> > James
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _________________________________________________________________________
>>>>> Professional FreeSWITCH Consulting Services:
>>>>> consulting at freeswitch.org
>>>>> http://www.freeswitchsolutions.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Official FreeSWITCH Sites
>>>>> http://www.freeswitch.org
>>>>> http://wiki.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://wiki.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
>>>>
>>>>
>>>
>>>
>>> --
>>> Anthony Minessale II
>>>
>>> FreeSWITCH http://www.freeswitch.org/
>>> ClueCon http://www.cluecon.com/
>>> Twitter: http://twitter.com/FreeSWITCH_wire
>>>
>>> AIM: anthm
>>> MSN:anthony_minessale at hotmail.com
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org
>>> googletalk:conf+888 at conference.freeswitch.org
>>> pstn:+19193869900
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>>
>>>
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.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://wiki.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
>>
>>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> googletalk:conf+888 at conference.freeswitch.org
> pstn:+19193869900
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
>
>
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.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/20131203/51cc0d04/attachment-0001.html
Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-users
mailing list