RTSP Client and multicast with AXIS cameras

[Federico Ares]

Hi,

I am trying to get an AXIS camera to work with RTSPClient class,
basing me on the openRTSP code.
There seems to be a problem when because RTSPClient expects
to receive the destination multicast address in the conection data field
of the SDP message (DESCRIBE response), but AXIS sends it in the
SETUP response message in the transport field.
The problem is that this field is not parsed for the destination and port
sub-fields and this information is lost.

I've succeeded to parse it correctly but I am not having luck in configuring
the media session to work with these ports and ip address. In fact, after
the PLAY, the server actually starts transmits the data (I made some network
dumps with Ethereal) but the RTSP client itself is not receiving the packets.
I think the RTP/RTCP ports are still not well configured in the media subsession
and thats why the packets are not being received correctly.

I also noticed that the AXIS camera can be asked via HTTP for the SDP
message, and that this message is not identical to the one given
via the DESCRIBE response. In fact the conection field contains the
multicast address instead of 0.0.0.0.
I havent tried yet to feed the media session with this SDP.

If anyone is familiar with these problems, or is currently having the same
difficulties, I would like to exchange ideas about getting this to work.
Right now I'm trying to guess which variables of the media subsession to change
to configure the ports correctly.

Have a nice day,

Federico Ares.
(Argentina)

This is the SETUP Response of an AXIS IP camera:

RTSP/1.0 200 OK

CSeq: 2

Session: 0299578912;timeout=60

Transport: RTP/AVP;multicast;mode=play;destination=224.0.0.2;port=1024-1025;ttl=255


This is the SDP message given by the server (DESCRIBE response)

RTSP/1.0 200 OK

CSeq: 1

Content-Base: rtsp://192.168.200.100:554/mpeg4/1/media.amp/

Content-Type: application/sdp

Content-Length: 684



v=0

o=- 1130347884978748 1130347884978758 IN IP4 192.168.200.100

s=Media Presentation

e=NONE

c=IN IP4 0.0.0.0

b=AS:8000

t=0 0

a=control:*

a=range:npt=now-

a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBUjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJQUFIb1NBQVlCQkE9PQQNAQUABAAAAAAAAAAAAAYJAQAAAAAAAAAAAzoAAkA2ZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAAAAAAAAAABQMAAEAGCQEAAAAAAAAAAA=="

m=video 0 RTP/AVP 96

b=AS:8000

a=control:trackID=1

a=rtpmap:96 MP4V-ES/90000

a=fmtp:96 profile-level-id=245; config=000001B0F5000001B50900000100000001200088401928582120A21F;

a=mpeg4-esid:201

[Derk-Jan Hartman]

Post by Federico Ares
Hi,
I am trying to get an AXIS camera to work with RTSPClient class,
basing me on the openRTSP code.
There seems to be a problem when because RTSPClient expects
to receive the destination multicast address in the conection data field
of the SDP message (DESCRIBE response), but AXIS sends it in the
SETUP response message in the transport field.
The problem is that this field is not parsed for the destination and port
sub-fields and this information is lost.

Mail Axis and yell at them :D

Post by Federico Ares
I've succeeded to parse it correctly but I am not having luck in configuring
the media session to work with these ports and ip address. In fact, after
the PLAY, the server actually starts transmits the data (I made some network
dumps with Ethereal) but the RTSP client itself is not receiving the packets.
I think the RTP/RTCP ports are still not well configured in the media subsession
and thats why the packets are not being received correctly.

that sounds reasonable.

Post by Federico Ares
I also noticed that the AXIS camera can be asked via HTTP for the SDP
message, and that this message is not identical to the one given
via the DESCRIBE response. In fact the conection field contains the
multicast address instead of 0.0.0.0.
I havent tried yet to feed the media session with this SDP.

Try feeding the HTTP served SDP file to VLC. It should be able to
pass it along to liveMedia quite easily. In the Messages window you
should be able to follow the results of the SETUP and PLAY.

Post by Federico Ares
If anyone is familiar with these problems, or is currently having the same
difficulties, I would like to exchange ideas about getting this to work.
Right now I'm trying to guess which variables of the media
subsession to change
to configure the ports correctly.
Have a nice day,
Federico Ares.
(Argentina)
RTSP/1.0 200 OK
CSeq: 2
Session: 0299578912;timeout=60
Transport: RTP/
AVP;multicast;mode=play;destination=224.0.0.2;port=1024-1025;ttl=255

AAaaaa. now you have to phone them, stalk them, put them over your
knee and spank their monkey asses. If there is one IP address in the
entire multicast range which you should never use for multicasting
video/audio, then it is the 224.0.0.2 address. (This address is used
by the multicast routers).

DJ

Post by Federico Ares
This is the SDP message given by the server (DESCRIBE response)
RTSP/1.0 200 OK
CSeq: 1
Content-Base: rtsp://192.168.200.100:554/mpeg4/1/media.amp/
Content-Type: application/sdp
Content-Length: 684
v=0
o=- 1130347884978748 1130347884978758 IN IP4 192.168.200.100
s=Media Presentation
e=NONE
c=IN IP4 0.0.0.0
b=AS:8000
t=0 0
a=control:*
a=range:npt=now-
a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoDUAE8BAf/
1AQOAbwABQFBkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBUjBCR3dVZ
kF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJQUFIb1NBQVlCQkE9PQQNAQUABAAAAAAAAAAAAAY
JAQAAAAAAAAAAAzoAAkA2ZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2N
Cx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAAAAAAAAAABQMAAEAGCQEAAAAAAAAAAA=="
m=video 0 RTP/AVP 96
b=AS:8000
a=control:trackID=1
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=245;
config=000001B0F5000001B50900000100000001200088401928582120A21F;
a=mpeg4-esid:201
_______________________________________________
live-devel mailing list
http://lists.live555.com/mailman/listinfo/live-devel

[Ross Finlayson]

Post by Federico Ares
There seems to be a problem when because RTSPClient expects
to receive the destination multicast address in the conection data field
of the SDP message (DESCRIBE response), but AXIS sends it in the
SETUP response message in the transport field.

It is highly unusual for a server to set up multicast streams in this way.

I'll see if I can modify the "RTSPClient" code to handle this.

In the meantime, if you can reconfigure your Axis server to stream
via unicast rather than multicast, then existing RTSP client software
(including ours) will likely work.


Ross Finlayson
Live Networks, Inc. (LIVE555.COM)
<http://www.live555.com/>

[Federico Ares]

Thank you Ross,

Thats right, the RTSPClient works perfectly with AXIS unicast servers.
I have done several implementation for these and had no problems at all.
It would be great if your libraries give support for the multicast servers.
I found that this behaviour about the SDP is mentioned in the RTSP RFC,
so I thought it was not so strange.

I'm trying to make the code work myself but I'm still unfamiliar with the
detailed
working principles of some classes (mediaSession for example).

I modified the RTSPClient::parseTransportResponse code to get the
"destination=" and "port=" fields. At least I got that right. :)

This is where I get lost. What shall I do with the parameters?

I tried redefining MediaSession::setDestinations() to accept RTP and RTCP
ports.
The method seems to be working in the sense it initializes the rtp and rtcp
sockets
with the values given in the SETUP response.

But still, the server starts transmitting, but no data is available from the
source.

Am I missing some other parameter to be configured so that the client reads
the
multicast packets?

Greetings and Thanks again,

Federico Ares

--------------------------------------------------------------------------------
For anyone who finds it useful, This is how I am parsing the SETUP response
to
gather the multicast data. I modified part of the parseTransportResponse
code.
This works ok.

Boolean RTSPClient::parseTransportResponse2 ( char const* line,

char*& multiAddressStr,

unsigned int* rtpPort,

unsigned int* rtcpPort)


unsigned int rtpTemp, rtcpTemp;
...................

while (sscanf(fields, "%[^;]", field) == 1)
{
if (sscanf(field, "port=%u-%u", &rtpTemp, &rtcpTemp) == 2)
{
foundClientPortNum = True;
}
if (_strncasecmp(field, "destination=", 12) == 0)
{
delete[] foundMultiAddressStr;
foundMultiAddressStr = strDup(field+12);
}
................
if (foundClientPortNum)
{
multiAddressStr = foundMultiAddressStr;
*rtpP= rtpTemp;
*rtcpP= rtcpTemp;
return True;
}

[Ross Finlayson]

FYI, I've now installed a new version (2005.11.02) of the "LIVE555
Streaming Media" code that updates the "RTSPClient" class. For
multicast streams, it will now use the "destination=" field in the
"SETUP" response's "Transport:" header. This should make it work
with weird servers - like your Axis camera - that do not set the
multicast address in the "DESCRIBE" response's SDP.


Ross Finlayson
Live Networks, Inc. (LIVE555.COM)
<http://www.live555.com/>

[Federico Ares]

Hi Ross,

I want to thank you for your quick response. I downloaded the code on
sourceforge, and built it with no problems.

Ive been trying the new code and I am still with the same problem. Some more
detailed info about it:

The first problem is in RTSPClient::setupMediaSubsession, when building the
SETUP message: transportTypeStr = IsMulticastAddress(connectionAddress) ?
";multicast" : ";unicast";

This line is not working well. The function IsMulticastAddress() recognizes
the null direction in the sdp (c= IN IP4 0.0.0.0) as an unicast address and
sends a unicast transmission SETUP, instead of a multicast SETUP. So, after
the PLAY, the server starts streaming unicast.

I added a bool parameter as input to the
RTSPClient::setupMediaSubsession(.... ,bool useMulticast)
and modified the line to this:

transportTypeStr = useMulticast? ";multicast" : ";unicast";

Second problem: I've been loking at the new parsing of the "destination="
field. I dont understand why you are assigning it to the
foundServerAddressStr variable. The server IP is still the same in
multicast. What changes is the destination address in the IP packet. Am I
very wrong?
I think you are missing also the port: field whis comes in the same message,
and specifies the RTP/RTCP port pair for multicast. e.g. "port: 3456-3457".
AXIS starts sending RTP packets from ServerAddress : 3456 to
MulticastAddress : 3456,
and RTCP packets from ServerAddress : 3457 to MulticastAddress : 3457.

The main problem seems to assign these address/port pair to the correct
variables in the media subsession. Thats what I've been trying to do but
without success. :)

Like I told you, the packets are there but the client doesnt recognize them.
If you give me some ideas of which variables from mediasession should I look
to confirm this, I could
do some more useful debugging of the problem.

Well, looking forward to receive your feedbak in this matter,
Thank you for your support.

Sincerely,

Federico


----- Original Message -----
From: "Ross Finlayson" <***@live555.com>
To: "LIVE555 Streaming Media - development & use"
<live-***@ns.live555.com>
Sent: Wednesday, November 02, 2005 7:51 AM
Subject: Re: [Live-devel] RTSP Client and multicast with AXIS cameras

Post by Ross Finlayson
FYI, I've now installed a new version (2005.11.02) of the "LIVE555
Streaming Media" code that updates the "RTSPClient" class. For multicast
streams, it will now use the "destination=" field in the "SETUP"
response's "Transport:" header. This should make it work with weird
servers - like your Axis camera - that do not set the multicast address in
the "DESCRIBE" response's SDP.
Ross Finlayson
Live Networks, Inc. (LIVE555.COM)
<http://www.live555.com/>
_______________________________________________
live-devel mailing list
http://lists.live555.com/mailman/listinfo/live-devel

[Ross Finlayson]

Post by Federico Ares
The first problem is in RTSPClient::setupMediaSubsession, when
building the SETUP message: transportTypeStr =
IsMulticastAddress(connectionAddress) ? ";multicast" : ";unicast";
This line is not working well. The function IsMulticastAddress()
recognizes the null direction in the sdp (c= IN IP4 0.0.0.0) as an
unicast address and sends a unicast transmission SETUP, instead of a
multicast SETUP. So, after the PLAY, the server starts streaming unicast.
I added a bool parameter as input to the
RTSPClient::setupMediaSubsession(.... ,bool useMulticast)

I have now installed a new version (2005.11.02a) of the code that
includes such a parameter. This (optional) parameter is called
"forceMulticastOnUnspecified"; see
"liveMedia/include/RTSPClient.hh". (Note that if you set this
parameter to True, then the previous parameters - "streamOutgoing"
and "streamUsingTCP" must be False.)

Post by Federico Ares
Second problem: I've been loking at the new parsing of the
"destination=" field. I dont understand why you are assigning it to
the foundServerAddressStr variable.

This is just a hack - don't worry about it. (What actually ends up
getting set is the 'connection endpoint' address, which - for a
multicast stream - is the multicast address, not the address of the server.)

Post by Federico Ares
I think you are missing also the port: field whis comes in the same
message, and specifies the RTP/RTCP port pair for multicast. e.g.
"port: 3456-3457".

Yes, I've now updated the "parseTransportResponse()" function to
recognize the "port=" field in the "Transport:" header (for multicast streams).


Ross Finlayson
Live Networks, Inc. (LIVE555.COM)
<http://www.live555.com/>

[kamil]

Hi,
Thank you for those improvements - I have waited for them too.

In fact it is called an 'Ax protocol' - which is some undocumented Microsoft
crap - see :http://www.axis.com/techsup/faq/index.php?id=53526.
Maybe if some more people complain about it Axis will fix it in some future
version.

Some other broken things in Axis protocol I noticed are:
1.
Timeout for multicast session - Axis232D stops sending multicast stream
after 60 seconds, I found following explanation:
http://www.axis.com/techsup/cam_servers/dev/cam_rtsp_api.htm
'If the Session header includes a timeout parameter, then the session needs
to be kept alive. This can be done by sending RTSP requests to the server
containing the session identifier (e.g. OPTIONS) within the specified
timeout time or through the use of RTCP.'
2.
Authorization for RTPoverHTTP is required in initial GET/POST requests ( eg.
header field 'Authorization: Basic xxxxx' ), and not only in tunneled RTSP.







_________________________________________________________________
List sprawdzony skanerem poczty mks_vir ( http://www.mks.com.pl )

[Federico Ares]

Hi,

I send a regular rtsp:// request for Axis Cameras. The RTSP transaction is
complete, and the multicast stream starts. I believe that "ax protocol" has
effect only on media player and will not affect RTSPClient's performance.

I still got some problems with the code:

In parseTransportResponse() I had to add a "return true;" line and comment
the "delete[] foundDestinationStr;" line. Otherwise parseTransportResponse
returns false even when multicast transport field is parsed correctly.

if (isMulticast && foundDestinationStr != NULL && foundMulticastPortNum)
{
delete[] foundServerAddressStr;
serverAddressStr = foundDestinationStr;
serverPortNum = multicastPortNumRTP;
return true; // add this line
}
//delete[] foundDestinationStr;

The code still doesnt work for me. Still have the same problem: the server
starts transmitting but there are no frames incoming. I'm starting to worry
about my own build. All other stuff seems normal.

I'll give it a look a couple of days and see what I can find out.

Have a nice weekend,

Federico Ares.

----- Original Message -----
From: "kamil" <***@poczta.onet.pl>
To: "LIVE555 Streaming Media - development & use"
<live-***@ns.live555.com>
Sent: Thursday, November 03, 2005 8:35 AM
Subject: Re: [Live-devel] RTSP Client and multicast with AXIS cameras

Post by kamil
Hi,
Thank you for those improvements - I have waited for them too.
In fact it is called an 'Ax protocol' - which is some undocumented
Microsoft crap - see :http://www.axis.com/techsup/faq/index.php?id=53526.
Maybe if some more people complain about it Axis will fix it in some
future version.
1.
Timeout for multicast session - Axis232D stops sending multicast stream
http://www.axis.com/techsup/cam_servers/dev/cam_rtsp_api.htm
'If the Session header includes a timeout parameter, then the session
needs to be kept alive. This can be done by sending RTSP requests to the
server containing the session identifier (e.g. OPTIONS) within the
specified timeout time or through the use of RTCP.'
2.
Authorization for RTPoverHTTP is required in initial GET/POST requests (
eg. header field 'Authorization: Basic xxxxx' ), and not only in tunneled
RTSP.
_________________________________________________________________
List sprawdzony skanerem poczty mks_vir ( http://www.mks.com.pl )
_______________________________________________
live-devel mailing list
http://lists.live555.com/mailman/listinfo/live-devel

[Ross Finlayson]

Post by Federico Ares
In parseTransportResponse() I had to add a "return true;" line and
comment the "delete[] foundDestinationStr;" line.

Oops - you're right (except for commenting out the "delete[]
foundDestinationStr;" line; you shouldn't do that).

I've now installed a new version that fixes this.

Post by Federico Ares
The code still doesnt work for me. Still have the same problem: the
server starts transmitting but there are no frames incoming. I'm
starting to worry about my own build. All other stuff seems normal.

I suggest first making sure that you can receive data OK using the
"openRTSP" application, before you try writing your own RTSP client.


Ross Finlayson
Live Networks, Inc. (LIVE555.COM)
<http://www.live555.com/>

[Federico Ares]

Thanks Ross,

I'll build openRTSP with the modified RTSPClient class and see what happens.

Regards,

Federico


----- Original Message -----
From: "Ross Finlayson" <***@live555.com>
To: "LIVE555 Streaming Media - development & use"
<live-***@ns.live555.com>
Sent: Thursday, November 03, 2005 12:42 PM
Subject: Re: [Live-devel] RTSP Client and multicast with AXIS cameras

Post by Ross Finlayson

Post by Federico Ares
In parseTransportResponse() I had to add a "return true;" line and comment
the "delete[] foundDestinationStr;" line.

Oops - you're right (except for commenting out the "delete[]
foundDestinationStr;" line; you shouldn't do that).
I've now installed a new version that fixes this.

Post by Federico Ares
The code still doesnt work for me. Still have the same problem: the server
starts transmitting but there are no frames incoming. I'm starting to
worry about my own build. All other stuff seems normal.

I suggest first making sure that you can receive data OK using the
"openRTSP" application, before you try writing your own RTSP client.
Ross Finlayson
Live Networks, Inc. (LIVE555.COM)
<http://www.live555.com/>
_______________________________________________
live-devel mailing list
http://lists.live555.com/mailman/listinfo/live-devel

[Federico Ares]

Hi DJ,

Thanks for your answer, you are right about the multicast address.

Post by Derk-Jan Hartman
AAaaaa. now you have to phone them, stalk them, put them over your
knee and spank their monkey asses. If there is one IP address in the
entire multicast range which you should never use for multicasting
video/audio, then it is the 224.0.0.2 address. (This address is used
by the multicast routers).

The range from 224.0.0.0 to 224.0.0.255 is reserved for routing protocols.
My mistake, so I could spank myself, ... maybe later... lotta work to do.
I changed it, but still no good news.

Post by Derk-Jan Hartman
"Try feeding the HTTP served SDP file to VLC. It should be able to
pass it along to liveMedia quite easily. In the Messages window you
should be able to follow the results of the SETUP and PLAY."

I cant quite figure out how to enter a SDP text into VLC. I guess you mean
without modifying the VLC code?

Greetings,

Federico