robertdoo / red5

Automatically exported from code.google.com/p/red5
0 stars 0 forks source link

createStream calls on high channels fail #458

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create an RTMP client that calls createStream
2. Change the RTMP chunk-stream ID that the createStream call is made on to be 
greater than 3 (lets say 4)
3. Red5 will report an error "Non-existant stream for channel id: 4, connection 
id: 42 discarding: {event}"

What is the expected output? What do you see instead?
I expect that this call will succeed - there's nothing in the (crappy) spec 
that says that createStream can't be called on an entirely new chunk-stream. 
Right now, Red5 says that any chunk-stream (channel) with an id higher than 3 
is a channel 'owned', and created by, Red5 itself.

I'm seeing clients out in the wild that are sending this call on channel 4, and 
because a Stream has yet to be created matching this channel, Red5 refuses to 
send a response. Instead, Red5 should send a response on the same chunk-stream 
(channel), with a Stream ID of 0.

What version of the product are you using? On what operating system?
Trunk, linux

Please provide any additional information below.

Please find a small patch fixing this problem attached.

Original issue reported on code.google.com by nchadw...@brightcove.com on 30 Oct 2013 at 9:14

Attachments:

GoogleCodeExporter commented 9 years ago
Your call is failing because there is no stream yet; create the stream and it 
will be assigned an id, which may or may not be 4.

Original comment by mondain on 31 Oct 2013 at 3:14

GoogleCodeExporter commented 9 years ago
The call is failing because Red5 doesn't actually create the stream until it 
receives a Play/Publish call, but some clients are sending their createStream 
packets on a channel that does not yet have a matching stream.

In this case, Red5 should respond to this call on Stream ID 0, rather than 
discarding the packets.

Attached is a small patch to rtmpdump/librtmp that reproduces the issue.

Original comment by nchadw...@brightcove.com on 31 Oct 2013 at 8:51

Attachments:

GoogleCodeExporter commented 9 years ago
I'm all for adding this functionality if you're fairly certain it should work 
this way. I see you're from brightcove, so I assume you have more insight that 
I do.

Original comment by mondain on 31 Oct 2013 at 9:00

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r4730.

Original comment by mondain on 31 Oct 2013 at 11:09