search

meetecho / janus-gateway

Janus WebRTC Server
https://janus.conf.meetecho.com
GNU General Public License v3.0
8.23k stars 2.48k forks source link

b2bua/third party call control prototype #162

Closed santokum closed 8 years ago

santokum commented 9 years ago

I have been toying with the idea of creating a thirdparty call control/b2bua/native client behind the gatway. As a prototype, i created a simple python script to register the user using videocall plugin and in tandem it creates the watch request using streaming plugin for generating offer SDP- as soon as it receives the offer SDP call is made to the browser user. Once the user answers the call, answer SDP from accept event is exchanged with streamplugin via start request. The call is getting answered from a signaling point of view, however there was no media-event sent to the streamplugin as a result there is no media sent from streamer.

I double checked the SDP’s/ICE all seems okay. I am guessing in this case janus_streaming_setup_media(janus_plugin_session *handle) not getting invoked as a result no streams are sent out even though DTLS connection is established…….. Perhaps i should investigate this in detail, but wanted to see if someone tried this useless already

on failed case: Browser is using existing videocall.js and on the second user side is python script [1513519930] Fingerprint is a match! [1513519930] Created inbound SRTP session for component 1 in stream 1 [1513519930] Created outbound SRTP session for component 1 in stream 1 [1513519930] The DTLS handshake for the component 1 in stream 1 has been completed [1513519930] The DTLS handshake has been completed [1513519930] Telling the plugin about it (JANUS VideoCall plugin) WebRTC media is now available [1513519930] Adding event to queue of messages... [1513519930] DTLS already set up, disabling retransmission timer! We have a message to serve... { "janus": "webrtcup", "session_id": 32129495, "sender": 1513519930 }

process:10760): libnice-DEBUG: Agent 0x1e21f00 : timer tick #451: 0 frozen, 1 in-progress, 0 waiting, 1 succeeded, 0 discovered, 1 nominated, 0 waiting-for-nom. (process:10760): libnice-DEBUG: Agent 0x1e21f00 : Packet received on local socket 28 from [192.168.0.10]:59942 (22 octets). STUN error: RTP or other non-protocol packet! [1513519930] Got an RTCP packet (video stream)! (process:10760): libnice-DEBUG: Agent 0x1e21f00 : timer tick #501: 0 frozen, 1 in-progress, 0 waiting, 1 succeeded, 0 discovered, 1 nominated, 0 waiting-for-nom. (process:10760): libnice-DEBUG: Agent 0x1e21f00 : Packet received on local socket 28 from [192.168.0.10]:59942 (22 octets). STUN error: RTP or other non-protocol packet! [

lminiero commented 9 years ago

WebRTC media is now available is the setup_media event you talked about (by the way, I assume you meant janus_videocall_setup_media and not janus_streaming_setup_media, which is from the streaming plugin), and the webrtcup event that follows is a notification on the client (JavaScript, or controlling application) side that all is ready. As such, I don't see why that should be a failed case.

santokum commented 9 years ago

Yes, not entirely sure why media is failing though....there was no 'started' event from videostream plugin. and no silly errors on SDP side either. I've spent most of last night looking into this. I am attaching logs, when you get a chance please let me know your thoughts. Many thanks

On Wed, 25/2/15, Lorenzo Miniero notifications@github.com wrote:

Subject: Re: [janus-gateway] b2bua/third party call control prototype (#162) To: "meetecho/janus-gateway" janus-gateway@noreply.github.com Cc: "santokum" santoshjram@yahoo.co.uk Date: Wednesday, 25 February, 2015, 9:28

WebRTC media is now available is the setup_media event you talked about (by the way, I assume you meant janus_videocall_setup_media and not janus_streaming_setup_media, which is from the streaming plugin), and the webrtcup event that follows is a notification on the client (JavaScript, or controlling application) side that all is ready. As such, I don't see why that should be a failed case.

— Reply to this email directly or view it on GitHub.

lminiero commented 9 years ago

But is the python script generating media or not? Where is the media the browser should get supposed to come from?

santokum commented 9 years ago

Nope, python script creates two session legs using RabbitMQ 1./ Watch(to get offer SDP) from stream plugin 2./ Register the user(Alice) into videocall plugin 3./ Makes a call toward User(Bob) using the streamplugin offer 4/ on receipt of accepted event from bob videoplugin answer SDP is extracted. 4. Start event is sent toward stream plugin with the answer SDP received from Bob Idea is to perform third party call control without creating any media, in this case Alice is python registered user with the media sdp as streamer and Bob is firefox registered user. Thanks

On Wed, 25/2/15, Lorenzo Miniero notifications@github.com wrote:

Subject: Re: [janus-gateway] b2bua/third party call control prototype (#162) To: "meetecho/janus-gateway" janus-gateway@noreply.github.com Cc: "santokum" santoshjram@yahoo.co.uk Date: Wednesday, 25 February, 2015, 10:08

But is the python script generating media or not? Where is the media the browser should get supposed to come from?

— Reply to this email directly or view it on GitHub.

santokum commented 9 years ago

Hiya, just wondered if you had a chance to look at the logs. please let me know your feedback when you get a chance. Many thanks

On Wed, 25/2/15, Santosh Kumar santoshjram@yahoo.co.uk wrote:

Subject: Re: [janus-gateway] b2bua/third party call control prototype (#162) To: "meetecho/janus-gateway" janus-gateway@noreply.github.com, "meetecho/janus-gateway" reply@reply.github.com Date: Wednesday, 25 February, 2015, 10:29

Nope, python script creates two session legs using RabbitMQ 1./ Watch(to get offer SDP) from stream plugin 2./ Register the user(Alice) into videocall plugin 3./ Makes a call toward User(Bob) using the streamplugin offer 4/ on receipt of accepted event from bob videoplugin answer SDP is extracted. 4. Start event is sent toward stream plugin with the answer SDP received from Bob Idea is to perform third party call control without creating any media, in this case Alice is python registered user with the media sdp as streamer and Bob is firefox registered user. Thanks

On Wed, 25/2/15, Lorenzo Miniero notifications@github.com wrote:

Subject: Re: [janus-gateway] b2bua/third party call control prototype  (#162) To: "meetecho/janus-gateway" janus-gateway@noreply.github.com Cc: "santokum" santoshjram@yahoo.co.uk Date: Wednesday, 25 February, 2015, 10:08

But is the python script generating media or not? Where is the media the browser should get supposed to come from?

— Reply to this email directly or view it on GitHub.

                       

lminiero commented 9 years ago

It's hard to debug as it's complex to replicate. You'll have to look at the admin API and/or wireshark dumps to see what's going wrong at a negotiation level.

santokum commented 9 years ago

After downing few peroni last night ;-), finally managed to identify the issue - It looks like a problem with ice trickle negotiation for this call flow.

I changed the following in sdp.c *trickle = 0; for removing trickle support for testing and added the TURN server on client side videocall.js iceServers: [{url: "turn:192.168.0.10:3478", username: "abc", credential: “xxxxx”}], Now it seem to work.

On Fri, 27/2/15, Lorenzo Miniero notifications@github.com wrote:

Subject: Re: [janus-gateway] b2bua/third party call control prototype (#162) To: "meetecho/janus-gateway" janus-gateway@noreply.github.com Cc: "santokum" santoshjram@yahoo.co.uk Date: Friday, 27 February, 2015, 10:24

It's hard to debug as it's complex to replicate. You'll have to look at the admin API and/or wireshark dumps to see what's going wrong at a negotiation level.

— Reply to this email directly or view it on GitHub.

lminiero commented 9 years ago

I don't think trickle is relevant here. If you're "bridging" two SDPs generated by Janus, you'll have all the candidates you need in the SDPs themselves, as Janus only does half trickle (it accepts trickle from browsers, while it aggregates all candidates in the SDP before sending it). This means that the candidates that are needed for communication are all there already on both sides.

If it worked with a relay, it probably means it was a reachability issue on the available host/srflx candidates, that only got the connectivity establishment to work through an external component.

santokum commented 9 years ago

Yes, but it seems to be waiting for gathering candidate stage with trickle being enabled. Even more bizare is that all of these node are in same subnet(192.168.0.16(GW),.15(browser)/24), i don't get how connectivity could be an issue. Needs more in depth looking into, for my prototype workaround seem to be doing the job for now.

On Mon, 2/3/15, Lorenzo Miniero notifications@github.com wrote:

Subject: Re: [janus-gateway] b2bua/third party call control prototype (#162) To: "meetecho/janus-gateway" janus-gateway@noreply.github.com Cc: "santokum" santoshjram@yahoo.co.uk Date: Monday, 2 March, 2015, 9:28

I don't think trickle is relevant here. If you're "bridging" two SDPs generated by Janus, you'll have all the candidates you need in the SDPs themselves, as Janus only does half trickle (it accepts trickle from browsers, while it aggregates all candidates in the SDP before sending it). This means that the candidates that are needed for communication are all there already on both sides.

If it worked with a relay, it probably means it was a reachability issue on the available host/srflx candidates, that only got the connectivity establishment to work through an external component.

— Reply to this email directly or view it on GitHub.

lminiero commented 9 years ago

Is it still an issue? If it is, can you share a simple webpage/application/something that can help us easily replicate it?

santokum commented 9 years ago

Hi Lorenzo, Not had a chance to look into this further, due to time constraint went with KMS and custom mobicent java code.

However, i am attaching the poor man's python script doing the 3pcc with static satemachine. Gateway was running on RaspberyPI, Script was running on mac and second user was on android.

Cheers, Santosh

On Wed, 8/7/15, Lorenzo Miniero notifications@github.com wrote:

Subject: Re: [janus-gateway] b2bua/third party call control prototype (#162) To: "meetecho/janus-gateway" janus-gateway@noreply.github.com Cc: "santokum" santoshjram@yahoo.co.uk Date: Wednesday, 8 July, 2015, 11:25

Is it still an issue? If it is, can you share a simple webpage/application/something that can help us easily replicate it?

— Reply to this email directly or view it on GitHub.

lminiero commented 8 years ago

Closing as too much has changed in the code since February. Feel free to open a new issue if you believe this is still a problem.