the sample demo in waiting status forever

[LayZhanger]

[sepfy]

hi, it's front-end issue. I just fixed it, please try again. Thanks

[LayZhanger]

hi, it's front-end issue. I just fixed it, please try again. Thanks

still have error :

[sepfy]

Please check if there are duplicate connections? It looks like there is already a connection in progress.

[LayZhanger]

Please check if there are duplicate connections? It looks like there is already a connection in progress.

I just tried again and it seems like there was no error, but there was no video stream

[AJamesChen]

This issue was introduced 2 days ago.

The state is never changed.
$ ./sample mqtt_eclipse_org.pem open https://sepfy.github.io/webrtc?deviceId=test_5524 INFO /home/git/libpeer/src/peer_connection.c 179 Datachannel allocates heap size: 153600 INFO /home/git/libpeer/src/peer_connection.c 184 Audio allocates heap size: 332800 INFO /home/git/libpeer/src/peer_connection.c 195 Video allocates heap size: 332800 INFO /home/git/libpeer/src/peer_signaling.c 138 Connecting to mqtt.eclipseprojects.io INFO /home/git/libpeer/src/peer_signaling.c 151 Subscribing to webrtc/test_5524/jsonrpc
Last week, it was working and log looked like as follows:
`$ ./sample mqtt_eclipse_org.pem
open https://sepfy.github.io/webrtc?deviceId=test_1871
INFO /home/git/libpeer/src/peer_connection.c 179 Datachannel allocates heap size: 153600
INFO /home/git/libpeer/src/peer_connection.c 184 Audio allocates heap size: 332800
INFO /home/git/libpeer/src/peer_connection.c 195 Video allocates heap size: 332800
INFO /home/git/libpeer/src/peer_signaling.c 138 Connecting to mqtt.eclipseprojects.io
INFO /home/git/libpeer/src/peer_signaling.c 151 Subscribing to webrtc/test_1871/jsonrpc
state is changed: new
INFO /home/git/libpeer/src/peer_connection.c 270 ice_servers: stun:stun.l.google.com:19302

INFO /home/git/libpeer/src/agent.c 164 resolved_addr.ipv4: 108.177.110.127
INFO /home/git/libpeer/src/agent.c 165 resolved_addr.port: 19302`

It seems the cause might be related to some changes in signalling and ice handling

Could you please help to fix it? thank you

[rjjrbatarao]

it seems like were thesame issue as in my previous post #40 it gives 0x0009 response im still working a way to decode its response code to get some clue

[darkuranium]

it seems like were thesame issue as in my previous post #40 it gives 0x0009 response im still working a way to decode its response code to get some clue

I assume you mean STUN attribute type 0x0009? That's an error code attribute. It consists of a 32-bit error code integer (which is not the 0x0009 code itself), plus a human-readable error string.

I have code to parse that response already, it's quite simple. (Warning: This code is debug-quality for my own WiP stuff, and is subject to buffer overflows and such!)

I've added this bit in stun_parse_msg_buf, where STUN_ATTR_TYPE_ERROR_CODE is a new StunAttrType defined as STUN_ATTR_TYPE_ERROR_CODE = 0x0009:

      case STUN_ATTR_TYPE_ERROR_CODE:
        LOGE("Error: %u - %.*s", (uint32_t)ntohl(*(uint32_t*)attr->value), attr->length - 4, attr->value + 4);
        break;