[Freeswitch-users] Getting FreeSWITCH to use RTP port + 1 for RTCP

Anthony Minessale anthony.minessale at gmail.com
Thu Nov 28 09:14:44 MSK 2013


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


Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-users mailing list