WebRTC when only TCP port 80 and 443 are open, and all UDP blocked.

[Anders Both]

Hello.

I have a rfc5766-turn-server installed on EC2 and listening on port 443 instead of 3478, and it works well for WebRTC in Chrome.

If one is on a cooporate network where only port 443 and 80 are open for TCP, and all UDP are blocked (except maybe UDP port 53 that are sometimes used by DNS), it seems to me that WebRTC is not working even when you have turnserver.

Is this because I am doing something wrong, or because I have to wait for turn/tcp support to land in chrome ?

Will WebRTC, in a later Chrome version, finally work through a corporate firewall where everything is blocked (except TCP in 80 and 443) ?

Best regards,

Anders 

 

[Mallinath Bareddy]

FYI Chrome canary has TURN tcp support now. We are working on adding proxy and TLS support which should take care corporate scenarios.

 

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Philipp Hancke]

TURN/TCP has recently landed in canary, see issue 1171. TURN/TLS isn't supported yet (see issues 1766/1425).

 

--

[Justin Uberti]

TURN/TCP to port 443 should work in most cases, as Mallinath mentions we are working on the few remaining cases.

[Anders Both]

Thanks - this is great news. I will test it in Canary again in a few weeks. 

[Bryan]

Does TURN/TCP have the same 2 second connection delay seen on host TCP candidates?

https://code.google.com/p/webrtc/issues/detail?id=1487

[Shachar]

Just a note:

rfc5766-turn-server (correct me if I'm wrong Oleg) will listen on the 443 for the STUN/TURN protocol if you configured it to, but then the relayed data will still be on arbitrary ports between 1024-65536 unless you configured that as well.

[Oleg Moskalenko]

Shachar, you are right - but the default relay ports range is different.

rfc5766-turn-server exactly follows TURN RFC 5766:

 - the default UDP and TCP listening port is 3478
 - the default TLS and DTLS listening port is 5349
 - the default relay port range is 49152 - 65535

But all those ports can be changed:

 - UDP and TCP listening port can be set with -p option, or with "listening-port" config file parameter;
 - TLS and DTLS port can be set with --tls-listening-port option and config file parameter;
 - the relay ports range can be set with --min-port and --max-port options and config file parameters.

So, if you are starting the turnserver process with "-p 443" then it will listen to 443 port.

Regards,
Oleg

[Mallinath Bareddy]

To make things little bitter TURN TCP has 1 second delay (as existing relay candidates allocation). We are working on removing these delays.

On Sat, May 18, 2013 at 10:47 AM, Bryan <bryand...@gmail.com> wrote:

Does TURN/TCP have the same 2 second connection delay seen on host TCP candidates?

https://code.google.com/p/webrtc/issues/detail?id=1487

[Oleg Moskalenko]

If WebRTC would add support for RFC 6062 (TCP relaying extension for TURN) then a proprietary solutions line vLine would not be needed.

On Tuesday, June 11, 2013 12:04:45 AM UTC-7, Matthew Robertson wrote:

in a recent Blog post, the vLine guys claimed that they are able to tunnel webRTC traffic over TCP using only port 443 and that it works in a way that "doesn’t rely on Chrome’s TURN implementation, so it works in Chrome today". I am going to test this on an enterprise network I am targeting tomorrow. 

Anybody have any idea how they might be doing this?

[Oleg Moskalenko]

Also, you cannot initiate contact from outside to an inside user in the enterprise, in general case, TCP or not. You will need something like a relay server, anyway. I was reading the vLine blog and they are not clear on the details, if they just introduce their own proprietary relay server then it makes no much sense.

[Justin Uberti]

I'm guessing vLine is using Chrome's built-in ICE-TCP support, which is standardized, and has been around for a while. 

Chrome 28 added TURN-TCP support as well, which is the simpler (and therefore recommended) path.

RFC 6062 isn't very useful in the WebRTC world, since it's rare that you want to make an outgoing TCP connection from a relay.

On Tue, Jun 11, 2013 at 9:54 AM, Oleg Moskalenko <mom0...@gmail.com> wrote:

Also, you cannot initiate contact from outside to an inside user in the enterprise, in general case, TCP or not. You will need something like a relay server, anyway. I was reading the vLine blog and they are not clear on the details, if they just introduce their own proprietary relay server then it makes no much sense.

--

[Oleg Moskalenko]

Justin, they cliam that they can do something that Chrome alone cannot do, read this:
..............................

"This is when our new TCP-tunneling support comes into play. It doesn’t rely on Chrome’s TURN implementation, so it works in Chrome today. Furthermore, it works even if both parties are behind firewalls that block UDP. All that’s required is access to the internet over port 443 (the HTTPS port), which the vast majority of firewalls allow."
..............................

This is all rather unclear. I do not see how a usual TURN TCP would be not enough to establish UDP relay endpoints and establish UDP media communications between the rely endpoints outside the enterprise network. The enterprise firewall can be perfectly traversed by TURN TCP between the clients and the TURN server.

Only if they indeed are establishing outgoing media connection from the relay endpoint their blog makes sense. And then RFC 6062 would help.

Regards,
Oleg

[Gustavo García]

TURN TCP would be also enough but it is not supported in Chrome 27. If your streams are already routed through some kind of cloud infrastructure you don't need TURN TCP but just support for ICE-TCP in your servers, it is the same we do today.

[Justin Uberti]

They're not using TURN - I think they're using ICE-TCP to a custom (non-TURN) relay server. (Presumably because they want this to work in Chrome 27).

On Tue, Jun 11, 2013 at 10:04 PM, Oleg Moskalenko <mom0...@gmail.com> wrote:

Justin, my understanding that this is not the case: they claim that they do NOT rely on Chrome's TCP support. Read what they are saying:

...............................................

"This is when our new TCP-tunneling support comes into play. It doesn’t rely on Chrome’s TURN implementation, so it works in Chrome today. Furthermore, it works even if both parties are behind firewalls that block UDP. All that’s required is access to the internet over port 443 (the HTTPS port), which the vast majority of firewalls allow."

...............................................

This is all rather unclear. They definitely are talking about outgoing media connection from a relay. Otherwise, I see no much sense: a usual TURN TCP would be enough to establish UDP relay endpoints and establish UDP media communications between the rely endpoints outside the enterprise network.

Only if they indeed are establishing outgoing media connection from the relay endpoint their blog makes sense. And then RFC 6062 would help.

Regards,
Oleg

On Tuesday, June 11, 2013 9:37:51 PM UTC-7, Justin Uberti wrote:

[Oleg Moskalenko]

This is what I was suspecting - a custom relay server, which is rather silly - all that to support older versions of Chrome.

[Oleg Moskalenko]

If WebRTC would really need proprietary elements in the infrastructure it would be a very bad thing for WebRTC as a technology. Hopefully, WebRTC can stay within standards. While reading vLine blog I got impression that they are saying something like "WebRTC is very cumbersome and a normal sane person cannot handle it - only our help and our special tools are making it practical".

[Justin Uberti]

Isn't that what jQuery says about web programming in general? Frameworks are there to provide abstraction.

[Oleg Moskalenko]

I just was thinking that the basic connectivity must be standardized and not requiring any proprietary network protocols and tools.

[Ben Strong]

Sorry I missed this conversation yesterday. As Justin suggested, we're using ICE-TCP and an out-of-band allocation protocol (we do this for UDP, as well). We went down this path for a few reasons:

1. When we first implemented this over a year ago, Chrome didn't support TURN at all, so this was the only way to build a working relay service. Of course there has been TURN UDP support in Chrome for a while now, but it will be several more months before we could rely on Chrome 28's TURN TCP support (our goal is to fully support at least the last three stable releases).
   
   
2. We're finding that while having both parties behind a firewall that blocks UDP is relatively rare for consumers in the US, it does happen somewhat frequently in enterprise settings. And it's a lot more common for ISPs to block UDP in other parts of the world, especially the Middle East (we're seeing some of the strongest interest in WebRTC coming from countries where other communication tools are blocked or monitored). So, we don't really see TURN TCP as being sufficient, anyway.
   
   
3. Even if it were implemented, we don't see RFC 6062 as a solution, since each allocation gets its own port. Since 443 is the only port you can reasonably rely on being open and not interfered with by a transparent proxy, we think it's critical for both sides to be able to connect to the same port (This is the part we just implemented. Before that, one of the parties would have to be on a different port).
   
   
4. We're not comfortable with using short-term TURN credentials as currently implemented. The problem is that if the session outlasts the TTL on the credentials and you have an ICE restart, then the new TURN allocation will fail. Since Justin mentioned this case in his proposal, I'm assuming there is work underway to allow you to update the credentials on an ICE restart, but to the best of my knowledge this is not currently implemented (I may be wrong here, since I haven't been following this one very closely).

We've never really thought of what we're doing for relay as being any more non-standard than the rest of the work we've done that's not part of the WebRTC standards but is needed by most real WebRTC applications (signaling, session management, presence, chat, widgets, APIs, etc.). The rationales for what should and shouldn't be standardized in WebRTC have never been particularly clear to me (e.g., if signaling is not standardized, then why is SDP part of the standard?). 

That said, I do think that a standard should probably exist that allows both endpoints to connect to the same port, and we'd be happy to contribute to the effort of defining one.

Ben

--

b...@vline.com

[Oleg Moskalenko]

Ben, could you pleas explain, how the description below is different from TURN TCP when the listening TURN server port is set as 443 ? Both parties behind their firewalls would connect through TURN TCP to the same 443 TCP port and exchange (UDP) data through the TURN TCP "tunnel".

[Justin Uberti]

Thanks for replying, Ben. I didn't really follow the discussion on #2/#3 though.

For #2, I would expect a topology like A <--- TCP --> TURN(A) <---- UDP ----> TURN(B) <---- TCP ---> B, where A and B both connect over 443 to their TURN servers.

So this should work with TURN/TCP, and also handle the case where multiple clients connect to the same port (for example, C, could connect to 443 on the same server as A).

[Oleg Moskalenko]

that is the same as what I was thinking. Usual TURN TCP has to be enough if both parties can utilize the normal connectivity procedure.

[Ben Strong]

For #2, I would expect a topology like A <--- TCP --> TURN(A) <---- UDP ----> TURN(B) <---- TCP ---> B, where A and B both connect over 443 to their TURN servers.

I had to go check the source code because when we started down this path, libjingle didn't allow relay->relay connections, but I guess that restriction was dropped when proper TURN support was added and I didn't notice. Certainly a viable way of doing it, which I agree means that what we're doing should not be strictly necessary once TURN TCP support is available.

We probably won't do this now for efficiency and backwards-compatibility reasons and because using a new UDP port for each allocation brings up port exhaustion issues at high allocation rates (one of the things I worry about is what the implications are if a developer builds an app that isn't a traditional call/conference model and winds up creating a large number of short-lived PeerConnections. Maybe some sort of P2P overlay network using data channels).

Ben

[Justin Uberti]

Not sure I follow your comment regarding port exhaustion. Are you worried about port exhaustion on the TURN server? If so, the TURN server could multiplex with only a few protocol changes.

--

[Oleg Moskalenko]

I guess Ben is talking about the UDP ports exhaustion in the TURN Server. Each TURN allocation requires a dedicated UDP relay port allocated. This is required by the specs and we cannot go around it. But really I do not think that this problem is very serious - there are techniques to avoid that (like multiple relay IP addresses configured on the TURN server, or  pool of load balanced multiple TURN servers). The client apps must be malicious and TURN server must be a special kind of hardware (to support that many clients in a single box) so that the UDP port exhaustion may become remotely real.

As in the particular case  we may not need the UDP ports (when we relay UDP traffic "internally") we theoretically can eliminate UDP ports and route the traffic "internally" inside single TURN server - with some TURN protocol changes. But the benefits of such an approach are minor, and the disadvantages are huge (non-standard protocol; elimination of load-balancing capabilities; etc) that I do not think that the "shortcut" solution is practical.

My opinion is that a good fully-featured TURN server implementation and Chrome 28+ are enough to solve the connectivity problem without unnecessary complications and tricks.

[Oleg Moskalenko]

Another useful tool against the UDP port exhaustion is the user quota - the max number of allocations a single user is allowed. This is an option of the TURN Server.

[Justin Uberti]

We could add a flag to the TURN protocol to enable multiplexing on a single external port, based on the ICE username that is presented in the media flows. But I agree, in almost all cases, this shouldn't be necessary.

On Thu, Jun 13, 2013 at 2:34 PM, Oleg Moskalenko <mom0...@gmail.com> wrote:

Another useful tool against the UDP port exhaustion is the user quota - the max number of allocations a single user is allowed. This is an option of the TURN Server.

[Oleg Moskalenko]

That's right, that would be a neat trick, if this is really required. If there will be real use cases and a real necessity, I can do that for rfc5766-turn-server - let me know please. Such a flag (STUN attribute) must be in 0x8000-0xFFFF range (comprehension-optional). That would allow both modified TURN Servers which understand the "trick", and that would allow backward compatibility with unmodified TURN servers, too - they simply will be ignoring the optional attribute and they will be allocating a new relay endpoint for each allocation, as per TURN standard.

The following numbers are already taken in the range of attributes: 0x8022, 0x8023, 0x8028, 0x8029, 0x802b, 0x802c. The new flag must be something else.

But hopefully we can do without that tweak :)

[Matthew Robertson]

Has anyone had any luck getting this to work? I been trying using RFC Turnserver on AWS and Chrome Canary  M29 and nothing:

I am booting the TURN server like this:

$ sudo turnserver -v --fingerprint --lt-cred-mech --static-auth-secret=SECRET --realm=ip-10-12-0-105 --external-ip=X.X.X.X --listening-port=443

and passing this as my PC_CONFIG:

{iceServers: [

  {url: "stun:stun.l.google.com:19302"},

  {url: "turn:us...@X.X.X.X:443?transport=tcp", credential: "PASSWORD"}

]}

One user is behind a firewall that blocks everything except TCP on 80 and 443 the other isn't. Am I doing something wrong?

[Oleg Moskalenko]

Matthew, you set the turnserver correctly - if your intention was to use TURN REST API.

You also have to set your webrtc server to use the REST API. The TURN server and the webrtc server have to use the same shared secret.

If the REST API was actually not your intention then you have to remove --static-auth-secret parameter and use whatever user names and passwords you have, either through the command line or userdb file or user database.

You can use wireshark to find out what is going on in your network - for example, whether your client is really talking to the TURN server and what kind of responses it is getting.

Oleg

[Matthew Robertson]

Hey Oleg,

Thanks for the advice, but the issue is not the authentication, I have confirmed that part is working (I just stubbed out the the authentication details in my commands). 

The issues I am having seem to be on the Chrome side only when UDP is blocked. Otherwise I can get connections through the TURN server working flawlessly. Has anybody been able to use Chrome M28+ to make a TURN connection on a network where UDP is blocked?

cheers,

Matthew

[Mallinath Bareddy]

Can you try with the latest chrome canary?

--

[Matthew Robertson]

I tried a few hours ago with canary 29.0.1541.0. I can test again tomorrow with whatever build is available then.

[Oleg Moskalenko]

Matthew, do you see any TURN TCP traffic coming to the TURN Server from webrtc client ?

[Matthew Robertson]

Hi Oleg,

yes I think I see both users attempting to connect to the turn server in the logs. Here is an excerpt:

1371685917: handle_turn_command: user <1371685900>: request ALLOCATE processed, error 0

1371685917: IPv4. tcp connected to: 184.69.146.182:54139

1371685917: handle_turn_command: user <>: message processed, error 401

1371685917: handle_turn_command: user <1371685900>: request CREATE_PERMISSION processed, error 0

1371685917: IPv4. Server relay addr: 10.12.0.105:0

1371685917: handle_turn_command: user <1371685884>: request ALLOCATE processed, error 0

1371685917: handle_turn_command: user <1371685884>: request CREATE_PERMISSION processed, error 0

1371685917: handle_turn_command: user <1371685884>: request CREATE_PERMISSION processed, error 0

1371685917: handle_turn_command: user <1371685884>: request CREATE_PERMISSION processed, error 0

1371685917: handle_turn_command: user <1371685900>: request CREATE_PERMISSION processed, error 0

1371685917: handle_turn_command: user <1371685884>: request CHANNEL_BIND processed, error 0

I have attached the entire turn log including the command used to boot the server to this post if you want to see more. 

I'm starting to question whether this is possible with the current implementation in Chrome Canary. Still haven't heard from anyone that has gotten it to work.

Matthew

[Oleg Moskalenko]

As far as I can see, Everything is authenticated correctly. Allocation and permissions are set properly.

Did you try it with a "real" TURN Server  - a server on a box with a real IP address ? may be something is in EC2 topology.

Ideally, a wireshark trace of network events would help. If you can determine which network entities send packets to which destinations in this case it would be helpful.

[Matthew Robertson]

Hey Oleg, 

I have attached a wireshark trace taken from the client that was behind the firewall. I set a filter to show only traffic where the destination IP is that of the TURN server. 

Interesting hypothesis that it might be related to Amazon network topology. I have set the security group for the instance to allow all TCP and UDP on all ports. Unfortunately, I don't have access to any servers that are not behind a NAT. We do have some non-EC2 servers that I could try to run the TURN server on but they are also behind a NAT.

BTW Thanks for all your help on this. If there is anything else you can think of that I might try please let me know.

Matthew

[Oleg Moskalenko]

Matthew, I guess the trace is incomplete - I see mostly one-way STUN traffic. I do not see return traffic from the TURN server.

To solve this, you have somehow to capture and separate the two-way traffic between the client and the TURN server. After examining the content (if any) we can say something.

There indeed may be problems with EC2 network filters, or else. If you are saying that the UDp case works, then I cannot think how the TCP case is different - except that the protocol between the client and the TURN server is TCP and may be some permissions have to be fixed.

I provide EC2 AMIs where I set the filters correctly, and I tested them with TCP - they work fine. But the filters are so simple that I doubt that you could make a mistake there.

I guess you have to get that capture. Just STUN/TURN messages, between the client and the TURN server. try to set the wireshark filter so that it will provide that - and in both ways.

Regards,
Oleg

[thomas kirk]

We're also failing to establish sessions through our firewall with canary; in our case, EC2 is not a factor, the TURN server is on the same subnet as the external endpoint. The firewall is slightly less restrictive, it allows outbound tcp on any port, as well as udp egress. Both hosts are getting udp and tcp candidates during ICE, and the internal host gets relay candidates, but they never go beyond that state.

(will follow up with packet trace)

[Matthew Robertson]

Hooray, I got it to work. It was an AWS issue. Seems to be the way the elastic IP addresses were mapped (our OPs guy set the scope to VPC).

THANK YOU everybody that helped me trouble shoot this. YOU ARE ALL AWESOME!!!

cheers,

Matthew

[Oleg Moskalenko]

Matthew, if you would provide more details what exactly was the problem, other people may find it useful, for future reference :)

Regards,
Oleg

[Anders Both]

I vote for that!.

[Matthew Robertson]

For sure I will. I only just got it working and I changed a few things at once so I only have a hypothesis on what fixed the issue. I am going to spend some more time digging in and discussing with our dev-ops guy to make sure I understand what was going on. When I know more I will be sure to fill you all in.

On Thursday, June 20, 2013 1:43:57 PM UTC-7, Anders Both wrote:

I vote for that!.

[Eugenio Andruskiewitsch]

Hi,
I have similar firewall restrictions only outbound TCP over 80 and 443 are allowed.
I'm developing an application using libjingle on windows and rfc5766-turn-server version "RFC 5389/5766/6062/6156 STUN/TURN Server, version Citrix-1.8.1.0 'Black Dow'"
Without the firewall restriction, the application works either using STUN or TURN depending on the network configuration, however I could not make the TCP-Relay to take over when restricting the firewall.
I was able to get the libjingle to create a TCP socket directly to the other pair, but that won't help in situations where both peers are behind similar firewall restrictions.
My linux server has a straight public address with no restrictions so far, but the relaying doesn't seem to take over. Is the LibJingle ready to work on RFC-6062? Am I missing some configuration?
From the libjingle peerconnection-client I'm using the following connection string: "turn:us...@xx.xxx.xxx.xxx:3636?transport=tcp"
On the linux server I ran the following: turnserver -L xx.xxx.xxx.xxx -p 3636 -f -v -a -r domain.org -o --no-udp --no-udp-relay

Any help would be very appreciated.

Thank you,

[Oleg Moskalenko]

Eugenio, TURN TCP in WebRTC means TCP communications between the client and the TURN server, but the relay transport is still UDP. This is how it is defined in RFC 5766.

RFC 6062 defines "full" TCP relay, when both client-to-server and the relay protocols are TCP/TLS. But WebRTC does not support RFC 6062 and there are no plans to add that support. Although rfc5766-turn-server supports RFC 6062, it is useless for now in WebRTC applications.

Another thing, as I mentioned in another thread, is that in your TURN server version (1.8.1.0) TURN TCP protocol implementation has a bug. Please upgrade to a fresh version.

[Oleg Moskalenko]

This interesting document summarizes the WebRTC communication patterns, including recommendations on TURN TCP usage:

http://tools.ietf.org/pdf/draft-hutton-rtcweb-nat-firewall-considerations-01.pdf

[Sergio Garcia Murillo]

Hi Oleg,

Excellent document, thank you very much to the autors (Justin, Thomas and Andrew).

Could it be possible to get a clear picture of what scenarios are currently supported today and by which chrome/firefox versions?

 2.1. NAT/Firewall open for outgoing UDP and TCP traffic
 2.2. NAT/Firewall open only for TCP traffic
 2.3. NAT/Firewall open only for TCP-based HTTP(s) traffic

Best regards
Sergio

El 28/06/2013 22:21, Oleg Moskalenko escribió:

This interesting document summarizes the WebRTC communication patterns, including recommendations on TURN TCP usage:

http://tools.ietf.org/pdf/draft-hutton-rtcweb-nat-firewall-considerations-01.pdf

[Albert Ollosa]

Hello Matthew, can you post some details about the fix with regards to the AWS issue? 

Is this fixed in the upcoming Chrome versions 30 and 31?

[David C]

This feature actually sounds pretty useful- the multiplexing on TURN server through single port. 

Has there been any status update regarding adding this to the rfc or anything?

[Anton Kirillov]

Hi,

We have our custom webRtc server implementation including stun/dtls handshake and further processing of srtp stream. The server has public IP and the server is not behind NAT. We faced the issue that some firewalls are blocking UDP hence looking for a simple way to pass rtp stream over TCP. Can we simply specify some kind option in SDP to allow client send STUN requests over TCP if UDP failed ? 

I don't have clear view how ICE, TURN work so far and now sure whether we really need turn-server installed. I believe if our media server can handle TCP stream along with UDP - it should be enough, it is correct ?

[Anton Kirillov]

Hi,

I read about TURN and it has its own protocol (allocation request etc), if our media-server try to handle TCP stream as it work with UDP (stun/dtsl/key-exchange/) it will not work for webRtc as I expected before.

Anyway if UDP traffic is blocked, looks like TURN server will not help anyway. I was thinking we can configure JS PeerConnection by specifying TCP turn server.

As Oleg mentioned Chrome does not support RFC 6062, even if communication between server and client is TCP, relay transport is still UDP. Not clear if it true for latest version of Chrome

[Kaiduan Xie]

You can use the topology like below,

1. Peer A connects to TURN server 1 over TCP on port 80 or 443, and
asks TURN server 1 to allocate a UDP port

2. Peer B connects to TURN server 2 over TCP on port 80 or 443, and
asks TURN server 2 to allocate a UDP port

3. TURN server 1 communicates with TURN server 2 over UDP

4. TURN server 1 and 2 can be on one physical box.

Make sense now :)

/Kaiduan

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "discuss-webrtc" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to discuss-webrt...@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/discuss-webrtc/c8e71be0-65de-4715-95e8-c6d76f451e73%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Anton Kirillov]

Hi,

In my case peer 2 is not a browser - it's Java server with public IP. Anyway proposed solution will not work because Chrome/FF will not send media data over TCP, TCP will be used only for signaling with TURN, media stream will be send over UDP to TURN. Full TCP relay is not supported yet by the browsers. Correct me if I am wrong and things have been changed.

[Boris Grozev]

You can use ICE/TCP (without a TURN server). See
https://tools.ietf.org/html/rfc6544
and
http://tools.ietf.org/html/rfc4571

Your server would need to advertise TCP candidates.

Regards,
Boris

[Anton Kirillov]

Thanks Boris. Should be relatively easy to implement it. Just wondering if all browsers support mentioned RFC.

вторник, 6 октября 2015 г., 1:18:03 UTC+3 пользователь Boris Grozev написал:

[Boris Grozev]

On 07/10/15 11:31, Anton Kirillov wrote:
> Thanks Boris. Should be relatively easy to implement it. Just wondering
> if all browsers support mentioned RFC.

AFAIK Chrome has supported it for a while, Firefox recently added it and
it's still behind a flag ("media.peerconnection.ice.tcp").


Regards,
Boris

[sam]

your server  can provide  tcp candidate to client,and client will connect use tcp,chrome had support tcp now.

在 2015年10月2日星期五 UTC+8上午1:32:48，Anton Kirillov写道：

[Anton Kirillov]

Hi,

Thanks all. I implemented packet shrine according to rfc4571. With fully blocked UDP traffic webRtc over TCP works fine in latest Chrome and Opera, does not work in FF through, I can see that FF local SDP does not contain any TCP ICE candidates.

1. Since all clients are using same TCP port - 80, not clear how to distinguish clients on server. For now I'm thinking about unique combination of client ip/port and username from STUN binding request. Not sure if it reliable enough. Wondering how vLine solved this issue.

2. Is there any standardized recommendation how to drop RTP packets if client TCP buffer is full and packets begin to accumulate in the internal queue ? I mean queue size, TTL and so on.

[quang minh]

I have this problem when I use different wifi, I can't make calls to each other, but when I connect to the same network, I can still make calls to each other. I don't know what's wrong, I hope everyone can help me. This is my source code.
I don't know if the error is due to my code or the configuration of stun/turn. I hope you can see my code and help me fix the error. Thank you very much.

Code Fe:
https://github.com/qminhminh/test_call_video_webrtc
BE:
https://github.com/qminhminh/call_wbrtc_server

@marcoberetta96 @MCYB @niyoceles

Note: errors from onicecandidateerror above are not necessarily fatal. For example an IPv6 DNS lookup may fail but relay candidates can still be gathered via IPv4.
The server stun:stun-connect.fcam.vn:3478 returned an error with code=701:
STUN host lookup received error.
The server turn:stun-connect.fcam.vn:3478?transport=udp returned an error with code=701:
TURN host lookup received error.

Error Log Flutter-Webrtc
https://github.com/qminhminh/webrtc_log_0_calll_video

Log Candidate:
https://github.com/qminhminh/can-iate_webrtc_call_log.

[quang minh]

I have this problem when I use different wifi, I can't make calls to each other, but when I connect to the same network, I can still make calls to each other. I don't know what's wrong, I hope everyone can help me. This is my source code.
I don't know if the error is due to my code or the configuration of stun/turn. I hope you can see my code and help me fix the error. Thank you very much.

Code Fe:
https://github.com/qminhminh/test_call_video_webrtc
BE:
https://github.com/qminhminh/call_wbrtc_server

@marcoberetta96 @MCYB @niyoceles

Note: errors from onicecandidateerror above are not necessarily fatal. For example an IPv6 DNS lookup may fail but relay candidates can still be gathered via IPv4.
The server stun:stun-connect.fcam.vn:3478 returned an error with code=701:
STUN host lookup received error.
The server turn:stun-connect.fcam.vn:3478?transport=udp returned an error with code=701:
TURN host lookup received error.

Error Log Flutter-Webrtc
https://github.com/qminhminh/webrtc_log_0_calll_video

Log Candidate:
https://github.com/qminhminh/can-iate_webrtc_call_log.

On Sunday, October 11, 2015 at 12:17:08 AM UTC+7 Anton Kirillov wrote:

[quang minh]

iceServer for me 

'iceServers': [
        {
          'urls': "stun:stun-connect.fcam.vn:3478",
        },
        {
          'urls': 'turn:stun-connect.fcam.vn:3478',
          'username': 'turnuser',
          'credential': "camfptvnturn133099",
        },
      ],
      'sdpSemantics': 'unified-plan',

On Sunday, October 11, 2015 at 12:17:08 AM UTC+7 Anton Kirillov wrote: