I’ve a call-flow, where A tries to set up a live stream to Wowza server (using RTSP ANNOUNCE/SETUP/RECORD), which would reflect it to B. However, when B tries to setup the RTSP session using DESCRIBE, the 200 OK to DESCRIBE from Wowza only contains incomplete SDP, with no media attributes, which make B give up on trying to play the video.
Here is the SDP in ANNOUNCE sent by A to Wowza:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 192.168.2.119
t=0 0
a=tool:libavformat 52.93.0
m=video 0 RTP/AVP 105
a=rtpmap:105 h264/90000
a=fmtp:105 profile-level-id=42e01e; packetization-mode=1; sprop-parameter-sets=Z0IACpZUCg+I,aM44gA==
a=control:streamid=0
m=audio 0 RTP/AVP 106
a=rtpmap:106 AMR/8000
a=fmtp:106 octet-align=1
a=control:streamid=1
and here is the incomplete SDP sent by Wowza to B, in 200 OK to DESCRIBE:
v=0
o=- 235374812 235374812 IN IP4 127.0.0.1
s=1111111111_27_03_2012_18_55_44.sdp
c=IN IP4 0.0.0.0
t=0 0
a=sdplang:en
a=range:npt=now-
a=control:*
I know that AMR as an audio codec is not supported by Wowza; however, even when I changed the audio codec to AAC also, the same problem persisted. One other thing of note is: in the SETUP(subsequent to ANNOUNCE) sent by A(handwritten client) to Wowza, A sends “mode=receive”, and doesn’t send the session ID sent back by Wowza in 200 OK to ANNOUNCE. Could this make Wowza refuse to reflect the session?
In the Wowza error logs, this is what I get:
WARN server comment 2012-03-27 18:57:16 - - - - - 11944.279 - - - - - - - - RTPStream.idle[235374812:live/definst:]: Close RTSP/RTP session. Session timeout: 90000
Could someone help? Thx.
In the experiment below, I wonder if this information has any bearing: A sets up the session with Wowza, using ANNOUNCE/SETUP/RECORD, but doesn’t send any RTP/RTCP packets after RECORD, and before the DESCRIBE from B comes into Wowza. Wonder, if this can cause Wowza to not put out media attributes in SDP with 200 OK for DESCRIBE.
I’ve a call-flow, where A tries to set up a live stream to Wowza server (using RTSP ANNOUNCE/SETUP/RECORD), which would reflect it to B. However, when B tries to setup the RTSP session using DESCRIBE, the 200 OK to DESCRIBE from Wowza only contains incomplete SDP, with no media attributes, which make B give up on trying to play the video.
Here is the SDP in ANNOUNCE sent by A to Wowza:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 192.168.2.119
t=0 0
a=tool:libavformat 52.93.0
m=video 0 RTP/AVP 105
a=rtpmap:105 h264/90000
a=fmtp:105 profile-level-id=42e01e; packetization-mode=1; sprop-parameter-sets=Z0IACpZUCg+I,aM44gA==
a=control:streamid=0
m=audio 0 RTP/AVP 106
a=rtpmap:106 AMR/8000
a=fmtp:106 octet-align=1
a=control:streamid=1
and here is the incomplete SDP sent by Wowza to B, in 200 OK to DESCRIBE:
v=0
o=- 235374812 235374812 IN IP4 127.0.0.1
s=1111111111_27_03_2012_18_55_44.sdp
c=IN IP4 0.0.0.0
t=0 0
a=sdplang:en
a=range:npt=now-
a=control:*
I know that AMR as an audio codec is not supported by Wowza; however, even when I changed the audio codec to AAC also, the same problem persisted. One other thing of note is: in the SETUP(subsequent to ANNOUNCE) sent by A(handwritten client) to Wowza, A sends “mode=receive”, and doesn’t send the session ID sent back by Wowza in 200 OK to ANNOUNCE. Could this make Wowza refuse to reflect the session?
In the Wowza error logs, this is what I get:
WARN server comment 2012-03-27 18:57:16 - - - - - 11944.279 - - - - - - - - RTPStream.idle[235374812:live/definst:]: Close RTSP/RTP session. Session timeout: 90000
Could someone help? Thx.
What is the encoder? How are you publishing? Is it using SDP announce? Or are you copying .sdp file to content folder then starting in StreamManager?
Exactly how are you reflecting to B?
Richard
I’m not sure what you are doing.
Richard
Hi,
This is not something we are able to do, and there aren’t any plans to add this.
Daren
Richard,
I got it working. The issue was that A wasn’t sending any RTP/RTCP packets, after sending ANNOUNCE/SETUP/SETUP/RECORD, and before B sent a DESCRIBE to Wowza server. Once A started sending RTP/RTCP right after RECORD, and before B sent a DESCRIBE(first of DESCRIBE/SETUP/SETUP/PLAY sequence), Wowza started reflecting.
Is there a way we could get a config parameter, in Wowza, for it to reflect, even when A may not have sent any RTP/RTCP packets before B’s DESCRIBE coming in? Thx.
-Sandeep
Richard,
The setup, for RTSP-based live streaming, is like this:
-
A sets up a live streaming session with Wowza, using RTSP ANNOUNCE, with sdp parameters.
-
A follows by sending 2 SETUPs for the 2 tracks(audio and video).
-
A then sends a RECORD message to Wowza, to begin live streaming. This is where the problem was: A didn’t send a sender report or any other RTP packet to Wowza.
-
B wants to join the live streaming session, and sends a DESCRIBE, with the same sdp file name that A had used, in ANNOUNCE, to set up the session.
-
Wowza didn’t send the media attributes in the sdp parameters, in 200 OK to the DESCRIBE, causing B to hang up on the session, as there’s nothing in sdp media attributes for B.
-
Now A starts sending RTP packets to Wowza.
The problem was resolved, if in item #3 above, A sends some RTP/RTCP packets after the RECORD message.
The question to Wowza is, can we get a config parameter, that will allow Wowza to respond to B’s DESCRIBE, with proper media attributes in sdp parameters of 200 OK, even though it may not have received any RTP/RTCP packets from A, after his RECORD message?
Plz let me know, if you understand the question better now. I can get on a quick call, to explain, if needed. Thx.
-Sandeep