FOOD FOR THOUGHT PIAF 3.0 Black on Amazon EC2 over CentOs 6.5 - STUN Issue

[pasamelo]

I've successfully installed a PIAF 3.0 Black with Asterisk 12.5.0 on Amazon EC2.

I had some issues that I will relate for reference:

- Corruption in frame.o file required manual deletion of this file and Asterisk compilation (make all, make install)
- No link to /lib64/libasteriskssl.so.1 (maybe related to the former issue)
- No Asterisk Start script in init/rc3.d
- Strange issue with php connection to DB : "Cannot make static method DB::connect() non static in class freepbx_db" required uninstallation of Pear DB module and installation of former version (1.7).

After all of this, my micro instance is working successfully.

But now I want to make WebRTC work, I need it! and I wish someone could show me a little of light.

It look like STUN server negotiation is not working, I've got correctly configured an STUN server but it looks like requests are never going out, Stun server never puts in the requests the external IP address, may be its normal but I dont have any expertise on this. Please look at this log:

(........many lines ........)

--- begin STUN message ---
STUN Binding request
Hdr: length=124, magic=2112a442, tsx_id=0000484b5c419dd97d9a91c8
Attributes:
  PRIORITY: length=4, value=1862270975 (0x6effffff)
  ICE-CONTROLLED: length=8, data=47ef2e51599bdffe
  SOFTWARE: length=12, value="pjnath-2.3.0"
  USERNAME: length=49, value="wRW+le2auoRFn1Gv:67b2360d060a996e19fae40069d6bf3a"
  MESSAGE-INTEGRITY: length=20, data=432f6d437228b31122cb86e81df12466161a18a3
  FINGERPRINT: length=4, value=1733866089 (0x6758b269)
--- end of STUN message ---
 
[2014-12-01 21:14:27] DEBUG[18542]: pjsip:0 <?>:        utsx0x7f999802 ...STUN client transaction created
[2014-12-01 21:14:27] DEBUG[18542]: pjsip:0 <?>:        utsx0x7f999802 ...STUN sending message (transmit count=1)
[2014-12-01 21:14:27] DEBUG[18542]: pjsip:0 <?>:        utsx0x7f999802 ....STUN error sending message: Invalid argument
[2014-12-01 21:14:27] DEBUG[18542]: pjsip:0 <?>:        stun_session.c ...tdata 0x7f9998028b58 destroy request, force=0, tsx=0x7f9998028d30
[2014-12-01 21:14:27] DEBUG[18542]: pjsip:0 <?>:        utsx0x7f999802 ...STUN transaction 0x7f9998028d30 schedule destroy
[2014-12-01 21:14:27] DEBUG[18542]: pjsip:0 <?>:        stuse0x7f999c5 ...Error sending STUN request: Invalid argument
[2014-12-01 21:14:27] ERROR[18542]: pjsip:0 <?>:        icess0x7f999c7 ..Error sending STUN request: Invalid argument

I sniffed with tcpdump and the requests are never sent...

Later, all requests fail:

[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        utsx0x7f179003 STUN timeout waiting for response
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        icess0x7f17900 .Check 0: [1] 192.168.253.151:14012-->192.168.1.39:51712 (not nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT)
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        icess0x7f17900 ..Check 0: [1] 192.168.253.151:14012-->192.168.1.39:51712: state changed from In Progress to Failed
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        stun_session.c .tdata 0x7f179003cd48 destroy request, force=1, tsx=0x7f179003cf20
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        utsx0x7f179003 .STUN client transaction 0x7f179003cf20 stopped, ref_cnt=9
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        utsx0x7f179800 STUN timeout waiting for response
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        icess0x7f17900 .Check 1: [2] 192.168.253.151:14013-->192.168.1.39:51712 (not nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT)
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        icess0x7f17900 ..Check 1: [2] 192.168.253.151:14013-->192.168.1.39:51712: state changed from In Progress to Failed
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        stun_session.c .tdata 0x7f17980016d8 destroy request, force=1, tsx=0x7f17980018b0
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        utsx0x7f179800 .STUN client transaction 0x7f17980018b0 stopped, ref_cnt=8
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        utsx0x7f179800 STUN timeout waiting for response
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        icess0x7f17900 .Check 2: [1] 192.168.253.151:14012-->83.60.46.159:51712 (not nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT)
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        icess0x7f17900 ..Check 2: [1] 192.168.253.151:14012-->83.60.46.159:51712: state changed from In Progress to Failed
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        stun_session.c .tdata 0x7f1798001ed8 destroy request, force=1, tsx=0x7f17980020b0
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        utsx0x7f179800 .STUN client transaction 0x7f17980020b0 stopped, ref_cnt=7
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        utsx0x7f179800 STUN timeout waiting for response
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        icess0x7f17900 .Check 3: [2] 192.168.253.151:14013-->83.60.46.159:51712 (not nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT)
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        icess0x7f17900 ..Check 3: [2] 192.168.253.151:14013-->83.60.46.159:51712: state changed from In Progress to Failed
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        stun_session.c .tdata 0x7f17980026d8 destroy request, force=1, tsx=0x7f17980028b0
[2014-12-01 22:07:14] DEBUG[21703]: pjsip:0 <?>:        utsx0x7f179800 .STUN client transaction 0x7f17980028b0 stopped, ref_cnt=6
[2014-12-01 22:07:18] DEBUG[21710]: acl.c:958 ast_find_ourip: Not an IPv4 nor IPv6 address, cannot get port.
[2014-12-01 22:07:18] DEBUG[21710]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting 'ip-192-168-253-151' into...
[2014-12-01 22:07:18] DEBUG[21710]: netsock2.c:226 ast_sockaddr_split_hostport: ...host 'ip-192-168-253-151' and port ''.
[2014-12-01 22:07:18] DEBUG[21710]: acl.c:958 ast_find_ourip: Not an IPv4 nor IPv6 address, cannot get port.
[2014-12-01 22:07:18] DEBUG[21710]: acl.c:963 ast_find_ourip: Attached to given IP address
[2014-12-01 22:07:23] DEBUG[21710]: acl.c:958 ast_find_ourip: Not an IPv4 nor IPv6 address, cannot get port.
[2014-12-01 22:07:23] DEBUG[21710]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting 'ip-192-168-253-151' into...
[2014-12-01 22:07:23] DEBUG[21710]: netsock2.c:226 ast_sockaddr_split_hostport: ...host 'ip-192-168-253-151' and port ''.
[2014-12-01 22:07:23] DEBUG[21710]: acl.c:958 ast_find_ourip: Not an IPv4 nor IPv6 address, cannot get port.

I think this is the last step to make WebRTC work , could someone help me please?

Thank you in advance.

 

[pasamelo]

Reading RFC3489 about STUN message format, it looks like USERNAME does not conform with required alignment.

Looking how to specify this attribute...

10.2.6  USERNAME
 
  The USERNAME attribute is used for message integrity.  It serves as a
  means to identify the shared secret used in the message integrity
  check.  The USERNAME is always present in a Shared Secret Response,
  along with the PASSWORD.  It is optionally present in a Binding
  Request when message integrity is used.
 
  The value of USERNAME is a variable length opaque value.  Its length
  MUST be a multiple of 4 (measured in bytes) in order to guarantee
  alignment of attributes on word boundaries.

Looks like someone else saw this before!

https://reviewboard.asterisk.org/r/4139/

 

[wardmundy]

pasamelo We've kinda thrown in the towel on Amazon EC2. It was just too quirky (and expensive) given the other Cloud options that are available. Glad to hear you got PIAF working with Asterisk 12 on the platform. I'll move this to the Bugs forum so Tom catches wind of the issues before releasing the next build. Thanks.

 

[pasamelo]

Thank you Ward!

I'm trying desperately to make WebRTC work in this environment and this looks like the last step (who knows)... I'll report if I success fixing it.

 

[pasamelo]

I fixed it!!!

After a very deep investigation the problem was that STUN candidates list was not being filled with Reflexive entries. It's caused by this function which returns false (don't know why) ast_sockaddr_is_ipv4(addr) in the file res_rtp_asterisk.c

So I patched to bypass this check and.... WebRTC is now working on EC2 in PIAF Black!! )

/* If configured to use a STUN server to get our external mapped address do so */

ast_debug(1, "Inserting SRFLX'\n" );
if (stunaddr.sin_addr.s_addr && /* ast_sockaddr_is_ipv4(addr) && */ count)

Thank you.

 

[pasamelo]

Another detected bug related with this issue, this time its a mix of Freepbx / Asterisk.

Freepbx does not permit define stunaddr in rtp.conf file, but STUN Reflex candidates are only included if stunaddr option is specified in the [general] section of rtp.conf. It's not valid to include it manually in the rtp_custom.conf file!! it must be defined on the original rtp_additional.conf file that is being writen by FreePBX.