meetecho / janode

A Node.js adapter for the Janus WebRTC server
ISC License
98 stars 36 forks source link

audiobridge startForward missing arguments? #11

Closed augustblack closed 2 years ago

augustblack commented 2 years ago

Hi,

I'm having trouble getting janode to start forwards. Using

Using the Janus api, I can properly start a forward with:

{
        "request" : "rtp_forward",
        "room" : <room name>,
        "codec" : "opus",
        "ptype" : 111,
        "host" : "localhost",
        "port" : <free port num>,
        "always_on" : true
}

and then be able to read the RTP stream with ffmpeg

However, with Janode, it seems ptype and codec are missing. I call:

janodeManagerHandle.startForward({
        "room" : <room name>,
        "host" : "localhost",
        "audio_port" : <free port num>,
        "secret": <..>,
        "always" : true
})

But, cannot read it with ffmpeg

Are the codec and ptype needed?

atoppi commented 2 years ago

Start your janode app with the argument --janode-log=debug and check the messages exchanged on the websocket. Is there something different from the working scenario?

augustblack commented 2 years ago

they are both running with the same Janus server.

When I start the rtp forward with the Janus api, (not janode) it works. When I start the rtp forward through janode, it doesn't not work.

I'm not sure what you are asking me to compare since only one uses Janode

I also only see keepalive and ack messages, nothing else really, eg:

 | 2022-06-12T19:55:47.326Z - DEBUG: [transport-ws.js] [114325528243876] <ws SND OK> {"janus":"keepalive","transaction":"114325528243890","session_id":5159841294464523,"apisecret":"..."}
process    | 2022-06-12T19:55:47.327Z - DEBUG: [transport-ws.js] [114325528243876] <ws RCV OK> {
process    |    "janus": "ack",
process    |    "session_id": 5159841294464523,
process    |    "transaction": "114325528243890"
process    | }
atoppi commented 2 years ago

ssrc, codec and ptype are still not present in the janode api but they are not mandatory for RTP forwarding.

Anyway I have tested with the audiobridge example and everything works as expected (latest janode and janus master)

2022-06-13T08:46:23.044Z - INFO : [index.js] [127.0.0.1:41494] rtp-fwd-start received
2022-06-13T08:46:23.045Z - VERB : [tmanager.js] [5635390075288042] created new transaction 4296580030590610, request "message"
2022-06-13T08:46:23.046Z - DEBUG: [transport-ws.js] [4296580030590600] <ws SND OK> {"janus":"message","body":{"request":"rtp_forward","room":1234,"host":"localhost","port":5111,"secret":"adminpwd"},"transaction":"4296580030590610","handle_id":5635390075288042,"session_id":829242068097661,"apisecret":"secret"}
2022-06-13T08:46:23.047Z - DEBUG: [transport-ws.js] [4296580030590600] <ws RCV OK> {
   "janus": "success",
   "session_id": 829242068097661,
   "transaction": "4296580030590610",
   "sender": 5635390075288042,
   "plugindata": {
      "plugin": "janus.plugin.audiobridge",
      "data": {
         "audiobridge": "success",
         "room": 1234,
         "stream_id": 3846489651,
         "host": "127.0.0.1",
         "port": 5111
      }
   }
}
2022-06-13T08:46:23.048Z - VERB : [handle.js] [5635390075288042] received success for transaction 4296580030590610
2022-06-13T08:46:23.048Z - VERB : [tmanager.js] [5635390075288042] closed with success transaction 4296580030590610, request "message"
2022-06-13T08:46:23.049Z - INFO : [index.js] [127.0.0.1:41494] rtp-fwd-started sent
lminiero commented 2 years ago

I'd suggest adding pt, ssrc and others because there are tools that may expect some precise values (eg, ffmpeg with payload types) that differ from what the browser is originating.

atoppi commented 2 years ago

I'd suggest adding pt, ssrc and others because there are tools that may expect some precise values (eg, ffmpeg with payload types) that differ from what the browser is originating.

Done, but again this is not relevant to the issue.

augustblack commented 2 years ago

Thanks for the attention and for adding the extra args (ptype, codec, etc).

My issue seems to have been unrelated to that and is now resolved.