d-vova / vs-stun Goto Github PK

For example:

I'm getting slice is not a function from:

https://github.com/d-vova/vs-stun/blob/master/lib/attribute/XORMappedAddress.js#L8
where result came from address.encode() which is returning Error objects, rather than throwing them:
https://github.com/d-vova/vs-stun/blob/master/lib/attribute/address.js#L26

a = new Error, a.slice()

So the consumer of this lib will never even see the correct error message.

currently, I have to do things like:

rinfo.host = rinfo.address;
responsePacket.append.mappedAddress(rinfo);
responsePacket.append.xorMappedAddress(rinfo);

If these functions took an object with the ip address as the host property of the argument object, I wouldn't need the first line. I suspect Node probably switched the name of these key value pairs at some point, but would make this lib's API nicer to work with. This is not a bug, just a small papercut.

https://www.ietf.org/mail-archive/web/ice/current/msg00247.html

I'm getting an error here: https://github.com/d-vova/vs-stun/blob/master/lib/attribute/address.js#L25-L26

It seems that the call to normalize: https://github.com/d-vova/vs-stun/blob/master/lib/attribute/address.js#L4

is not parsing ipv6 addresses correctly: https://github.com/d-vova/vs-stun/blob/master/lib/util.js#L20

does not match my ipv6 address of 2620:101:80fc:232:2acf:e9ff:fe1f:3939.

I'm wondering if https://nodejs.org/api/net.html#net_net_isip_input can be used instead?

so I need to be able to shut down the stun server, I need to be able to cancel existing timeouts, like the one here: https://github.com/d-vova/vs-stun/blob/master/lib/client.js#L191-L233

Otherwise, I'll get issues when I close the underlying socket.

I love this library, but it is failing against the Coturn server (https://code.google.com/p/coturn/). Coturn is returning the OTHER-ADDRESS attribute in its initial response, which puts vs-stun into trying to map to OTHER-ADDRESS.

OTHER-ADDRESS in this case usually has a different port, but vs-stun sends its request to the new address but the old port. I don't know the STUN RFC inside and out, but I'm guessing that this line may be a bug:

var otser = { host: other.host, port: server.port }

In the normal case, the initial request and response are on port 3478, and the OTHER-ADDRESS is the same address but port 3479. The second request goes out to port 3478, and the second reply comes back from 3479, which will then get dropped or rejected by normal firewall rules. This causes vs-stun to timeout, saying that UDP is blocked, even though the initial binding response was fine.

https://github.com/d-vova/vs-stun/blob/master/lib/attribute/UseCandidate.js#L12

Needs to do more work as specified by https://tools.ietf.org/html/rfc5389#section-15.4. I need this check to comply with https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-00#section-6.2 for https://github.com/nickdesaulniers/node-rtc-peer-connection.

Excellent lib by the way, I'm using it in the above linked project.