webrtcbin not working in remote networks

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

webrtcbin not working in remote networks

givip
I have a webrtcbin, which purpose is only send video stream to browser.

When I test this locally on computer (same IP) or in local Network (Wi-Fi),
everything works video stream is displaying well, when I try to move one
peer to other network, for example LTE, I receive errors on browser side.
I use PeerJS for signalling, but I think this cannot be a reason.

- STUN/TURN servers are added on both sides and works, tested here
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ 
- I send offer from webrtcbin side
- I don't send ice-candidates from webrtcbin side, because browser rejects
them (I suppose because answer contains 'end-of-candidates' statment)

In attach you can see Offer, Answer and whole connection log from Firefox.

webrtc_sendonly_remote_network.txt
<http://gstreamer-devel.966125.n4.nabble.com/file/t378892/webrtc_sendonly_remote_network.txt>  

Thanks for advance!



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: webrtcbin not working in remote networks

Matthew Waters
Hi,

I note that the session identifier in the two SDP's are different
5751836003214404839 != 5901274869285265006.  This means that that there
are two separate sessions in progress and the SDP's do not describe the
same connection.  Are you sure that you are performing the correct order
of signalling?

If you don't send ICE candidates in one direction, then it is entirely
likely that the connection may fail.

Cheers
-Matt

On 6/11/19 6:05 am, givip wrote:

> I have a webrtcbin, which purpose is only send video stream to browser.
>
> When I test this locally on computer (same IP) or in local Network (Wi-Fi),
> everything works video stream is displaying well, when I try to move one
> peer to other network, for example LTE, I receive errors on browser side.
> I use PeerJS for signalling, but I think this cannot be a reason.
>
> - STUN/TURN servers are added on both sides and works, tested here
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ 
> - I send offer from webrtcbin side
> - I don't send ice-candidates from webrtcbin side, because browser rejects
> them (I suppose because answer contains 'end-of-candidates' statment)
>
> In attach you can see Offer, Answer and whole connection log from Firefox.
>
> webrtc_sendonly_remote_network.txt
> <http://gstreamer-devel.966125.n4.nabble.com/file/t378892/webrtc_sendonly_remote_network.txt>  
>
> Thanks for advance!

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: webrtcbin not working in remote networks

givip
I tried to fix mentioned problems:
- I tried to transform generated SDP by browser to match session id from
offer, so webrtcbin received answer with same ID, but this doesn't work.
Please notice, that I can connect from other browser to demo page and video
stream works well. Check demo page links in the end of message.
- I changed way of how I send ICE candidates, because classical way trough
Signalling server gave me errors on browser side. Now I send it not after
offer, but I injected all of them directly in offer, as 'a=candidate: ...'.
Still no sense.

Here the step-by-step description of how my program works:
Prerequisites: I have two gstreamer pipelines:
    - one with appsrc in head and webrtcbin for video channel in tail. We
will call it "Data webrtcbin" below.
    - other sole webrtcbin for data channel (I tried to encapsulate this in
one webrtcbin, but this doesn't want to work together at all) We will call
it "Video webrtcbin" below.

1. Browser establish data channel connection with "Data webrtcbin". Works in
both direction in any networks perfectly.
2. Browser's user asks to send video stream by sending special command
trough data channel (let's say 'CALLME')
3. "Data webrtcbin" receive message and ask "Video webrtcbin" to create
offer.
4. "Video webrtcbin" gathers ice-candidates.
5. After ice-gathering-status is COMPLETED, all ICE candidates have been
added to offer as attribute.
6. Send Offer to signalling server.
7. Receive Answer from browser (without any candidates).
8. Receive ICE candidates from Signalling server.
9. Adding ICE candidates to "Video webrtcbin".

Works in local networks perfectly! Not work in other networks.

May be Ice candidates, that I received from browser (trough signalling
server, not in answer), are inaccessible?
Here is log  webrtcbin_log.txt
<http://gstreamer-devel.966125.n4.nabble.com/file/t378892/webrtcbin_log.txt>  

Also you can play yourself with my signalling server, maybe that will help:
https://gp-apps.com/peer/send.html <https://gp-apps.com/peer/send.html>  
https://gp-apps.com/peer/receive.html
<https://gp-apps.com/peer/receive.html>  
   



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: webrtcbin not working in remote networks

Matthew Waters
This sounds unnecessarily complicated and depending on the version of
GStreamer used, may already work.

Renegotiating is currently something of limited support that was only
recently added in master.  You could try that instead of your dual
webrtcbin's if that helps.

This sounds like what you're doing should work assuming you're passing
the correct information between the correct peerconnection instances in
the browser and the correct webrtcbin instance though which is something
that's not explicitly mentioned that you're doing :).

The ICE candidate gathering and adding to the SDP step from the
webrtcbin is not strictly necessary as browsers have supported trickled
ICE candidates for a long time.

You could grab a GST_DEBUG=3,*webrtc*:7 to trawl through to see the
exact sequence of events passed to both webrtcbin elements and whether
it makes sense.

Cheers
-Matt

On 7/11/19 3:41 am, givip wrote:

> I tried to fix mentioned problems:
> - I tried to transform generated SDP by browser to match session id from
> offer, so webrtcbin received answer with same ID, but this doesn't work.
> Please notice, that I can connect from other browser to demo page and video
> stream works well. Check demo page links in the end of message.
> - I changed way of how I send ICE candidates, because classical way trough
> Signalling server gave me errors on browser side. Now I send it not after
> offer, but I injected all of them directly in offer, as 'a=candidate: ...'.
> Still no sense.
>
> Here the step-by-step description of how my program works:
> Prerequisites: I have two gstreamer pipelines:
>     - one with appsrc in head and webrtcbin for video channel in tail. We
> will call it "Data webrtcbin" below.
>     - other sole webrtcbin for data channel (I tried to encapsulate this in
> one webrtcbin, but this doesn't want to work together at all) We will call
> it "Video webrtcbin" below.
>
> 1. Browser establish data channel connection with "Data webrtcbin". Works in
> both direction in any networks perfectly.
> 2. Browser's user asks to send video stream by sending special command
> trough data channel (let's say 'CALLME')
> 3. "Data webrtcbin" receive message and ask "Video webrtcbin" to create
> offer.
> 4. "Video webrtcbin" gathers ice-candidates.
> 5. After ice-gathering-status is COMPLETED, all ICE candidates have been
> added to offer as attribute.
> 6. Send Offer to signalling server.
> 7. Receive Answer from browser (without any candidates).
> 8. Receive ICE candidates from Signalling server.
> 9. Adding ICE candidates to "Video webrtcbin".
>
> Works in local networks perfectly! Not work in other networks.
>
> May be Ice candidates, that I received from browser (trough signalling
> server, not in answer), are inaccessible?
> Here is log  webrtcbin_log.txt
> <http://gstreamer-devel.966125.n4.nabble.com/file/t378892/webrtcbin_log.txt>  
>
> Also you can play yourself with my signalling server, maybe that will help:
> https://gp-apps.com/peer/send.html <https://gp-apps.com/peer/send.html>  
> https://gp-apps.com/peer/receive.html
> <https://gp-apps.com/peer/receive.html>  
>    
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: webrtcbin not working in remote networks

givip
Thank you for good answer, as you said everything should work.

Today I found the problem.

My Signalling server (PeerJS) does some classification of candidates on
server-side and requires sdpMid param to be passed on server. Because
webrtcbin doesn't provide this parameter explicitly on "on-ice-candidate"
callback I hardcoded it to "0" and this was the problem.

Because in case of video stream it's "video0"

My browser didn't attach ICE candidates cause server didn't pass them
correctly and throw error.

My advice, to add this parameter in "on-ice-candidate" callback, I can do
that myself, but later.


Matthew Waters wrote

> This sounds unnecessarily complicated and depending on the version of
> GStreamer used, may already work.
>
> Renegotiating is currently something of limited support that was only
> recently added in master.  You could try that instead of your dual
> webrtcbin's if that helps.
>
> This sounds like what you're doing should work assuming you're passing
> the correct information between the correct peerconnection instances in
> the browser and the correct webrtcbin instance though which is something
> that's not explicitly mentioned that you're doing :).
>
> The ICE candidate gathering and adding to the SDP step from the
> webrtcbin is not strictly necessary as browsers have supported trickled
> ICE candidates for a long time.
>
> You could grab a GST_DEBUG=3,*webrtc*:7 to trawl through to see the
> exact sequence of events passed to both webrtcbin elements and whether
> it makes sense.
>
> Cheers
> -Matt
>
> On 7/11/19 3:41 am, givip wrote:
>> I tried to fix mentioned problems:
>> - I tried to transform generated SDP by browser to match session id from
>> offer, so webrtcbin received answer with same ID, but this doesn't work.
>> Please notice, that I can connect from other browser to demo page and
>> video
>> stream works well. Check demo page links in the end of message.
>> - I changed way of how I send ICE candidates, because classical way
>> trough
>> Signalling server gave me errors on browser side. Now I send it not after
>> offer, but I injected all of them directly in offer, as 'a=candidate:
>> ...'.
>> Still no sense.
>>
>> Here the step-by-step description of how my program works:
>> Prerequisites: I have two gstreamer pipelines:
>>     - one with appsrc in head and webrtcbin for video channel in tail. We
>> will call it "Data webrtcbin" below.
>>     - other sole webrtcbin for data channel (I tried to encapsulate this
>> in
>> one webrtcbin, but this doesn't want to work together at all) We will
>> call
>> it "Video webrtcbin" below.
>>
>> 1. Browser establish data channel connection with "Data webrtcbin". Works
>> in
>> both direction in any networks perfectly.
>> 2. Browser's user asks to send video stream by sending special command
>> trough data channel (let's say 'CALLME')
>> 3. "Data webrtcbin" receive message and ask "Video webrtcbin" to create
>> offer.
>> 4. "Video webrtcbin" gathers ice-candidates.
>> 5. After ice-gathering-status is COMPLETED, all ICE candidates have been
>> added to offer as attribute.
>> 6. Send Offer to signalling server.
>> 7. Receive Answer from browser (without any candidates).
>> 8. Receive ICE candidates from Signalling server.
>> 9. Adding ICE candidates to "Video webrtcbin".
>>
>> Works in local networks perfectly! Not work in other networks.
>>
>> May be Ice candidates, that I received from browser (trough signalling
>> server, not in answer), are inaccessible?
>> Here is log  webrtcbin_log.txt
>> &lt;http://gstreamer-devel.966125.n4.nabble.com/file/t378892/webrtcbin_log.txt&gt;   
>>
>> Also you can play yourself with my signalling server, maybe that will
>> help:
>> https://gp-apps.com/peer/send.html
>> &lt;https://gp-apps.com/peer/send.html&gt; 
>> https://gp-apps.com/peer/receive.html
>> &lt;https://gp-apps.com/peer/receive.html&gt; 
>>    
>>
>>
>>
>> --
>> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>> _______________________________________________
>> gstreamer-devel mailing list
>>

> gstreamer-devel@.freedesktop

>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
>
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel@.freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> signature.asc (499 bytes)
> &lt;http://gstreamer-devel.966125.n4.nabble.com/attachment/4692556/0/signature.asc&gt;





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel