I am using Live555 streaming media for an application which records and re-streams RTSP streams coming from IP camera. For that, I am using openRTSP for recording and live555 proxy server for re-streaming the camera stream. For a few of the cameras we are facing a strange issue where in the camera recording happens successfully, however the live555 proxy server is unable to generate a new stream for the same camera stream (there is no indication of failure in the verbose output dump, however the rtsp url generated by proxy server cannot be decoded by an rtsp client). Since I do not have any idea about the live555 proxy server details, I have been unable to get into this problem. I tried streaming the same camera stream using VLC and that works fine. What could be possibly wrong with this. I am hereby attaching the verbose output for reference.
E:\...\live\proxyServer>live555ProxyServer.exe -V rtsp://10.17.10.67/ch0_unicast_firststream
LIVE555 Proxy Server
(LIVE555 Streaming Media library version 2012.05.17)
Opening connection to 10.17.10.67, port 554...
RTSP stream, proxying the stream "rtsp://10.17.10.67/ch0_unicast_firststream"
Play this stream using the URL "rtsp://10.17.1.150/proxyStream"
(We use port 8000 for optional RTSP-over-HTTP tunneling.)
...remote connection opened
Sending request: DESCRIBE rtsp://10.17.10.67/ch0_unicast_firststream RTSP/1.0
CSeq: 2
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Accept: application/sdp
Received 716 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
CSeq: 2
Date: Wed, Jul 04 2012 10:55:19 GMT
Content-Base: rtsp://10.17.10.67/ch0_unicast_firststream/
Content-Type: application/sdp
Content-Length: 540
v=0
o=- 1341385393116860 1 IN IP4 10.17.10.67
s=Session of first stream
i=First Codec Stream
t=0 0
a=tool:LIVE555 Streaming Media v2007.08.03
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:Session of first stream
a=x-qt-text-inf:First Codec Stream
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=5;config=000001B005000001B509000001000000012000847A98
28A02240A31F
a=control:track1
m=metadata 0 RTP/AVP 97
c=IN IP4 0.0.0.0
a=rtpmap:97 METADATA/64000
a=control:track2
ProxyServerMediaSession["rtsp://10.17.10.67/ch0_unicast_firststream/"] added new
"ProxyServerMediaSubsession" for RTP/video/MP4V-ES track
ProxyServerMediaSession["rtsp://10.17.10.67/ch0_unicast_firststream/"] added new
"ProxyServerMediaSubsession" for RTP/metadata/METADATA track
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 3
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 122 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 3
Date: Wed, Jul 04 2012 10:55:56 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Opening connection to 10.17.10.67, port 554...
...remote connection opened
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 4
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 122 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Jul 04 2012 10:56:48 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Opening connection to 10.17.10.67, port 554...
...remote connection opened
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 5
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 122 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 5
Date: Wed, Jul 04 2012 10:57:43 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 6
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 122 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Jul 04 2012 10:58:23 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 7
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 122 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 7
Date: Wed, Jul 04 2012 10:59:04 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 8
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
ProxyRTSPClient["rtsp://10.17.10.67/ch0_unicast_firststream/"]: lost connection
to server ('errno': 10057). Resetting...
Opening connection to 10.17.10.67, port 554...
...remote connection opened
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 9
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 122 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 9
Date: Wed, Jul 04 2012 11:00:29 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Opening connection to 10.17.10.67, port 554...
...remote connection opened
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 10
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 123 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 10
Date: Wed, Jul 04 2012 11:01:22 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 11
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 123 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 11
Date: Wed, Jul 04 2012 11:02:05 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 12
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 123 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 12
Date: Wed, Jul 04 2012 11:02:39 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 13
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 123 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 13
Date: Wed, Jul 04 2012 11:03:10 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/ RTSP/1.0
CSeq: 14
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.05.17)
Received 123 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 14
Date: Wed, Jul 04 2012 11:03:46 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Awaiting your response.
Regards,
Saurabh Gandhi
It could be mostly because of udp ports blocked because of firewalls. Try -t flag to force the transmission through tcp.
Related
I'm implementing an RTSP server in NodeJs, using the RFC's (rtsp, rtp, sdp) and this tutorial.
I'm using VLC to test my implementation, and it works fine for the example (link at the bottom of the tutorial) but stops halfway for my server.
I'm suspecting some RFC compliance issue, but I can't find it, and VLC isn't really providing any useful information as to what it's doing.
Running wireshark and the c++ server implementation, and pointing VLC to it shows all the steps:
OPTIONS rtsp://192.168.10.151:8554/mjpeg/1 RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.2.1 (LIVE555 Streaming Media v2014.07.25)
RTSP/1.0 200 OK
CSeq: 2
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
DESCRIBE rtsp://192.168.10.151:8554/mjpeg/1 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.2.1 (LIVE555 Streaming Media v2014.07.25)
Accept: application/sdp
RTSP/1.0 200 OK
CSeq: 3
This should be date
Content-Base: rtsp://192.168.10.151:8554/mjpeg/1/
Content-Type: application/sdp
Content-Length: 90
v=0
o=- 6334 1 IN IP4 192.168.10.151
s=
t=0 0
m=video 0 RTP/AVP 26
c=IN IP4 0.0.0.0
SETUP rtsp://192.168.10.151:8554/mjpeg/1/ RTSP/1.0
CSeq: 4
User-Agent: LibVLC/2.2.1 (LIVE555 Streaming Media v2014.07.25)
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
RTSP/1.0 200 OK
CSeq: 4
This should be date
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Session: -2144778205
PLAY rtsp://192.168.10.151:8554/mjpeg/1/ RTSP/1.0
CSeq: 5
User-Agent: LibVLC/2.2.1 (LIVE555 Streaming Media v2014.07.25)
Session: -2144778205
Range: npt=0.000-
RTSP/1.0 200 OK
CSeq: 5
This should be date
Range: npt=0.000-
Session: -2144778205
RTP-Info: url=rtsp://127.0.0.1:8554/mjpeg/1/track1
And the VLC messages:
...
live555 debug: RTP subsession 'video/JPEG'
core debug: selecting program id=0
live555 debug: setup start: 0.000000 stop:0.000000
live555 debug: play start: 0.000000 stop:0.000000
core debug: using access_demux module "live555"
core debug: looking for decoder module matching "any": 43 candidates
...
When I run my own server, it never sends the play request:
OPTIONS rtsp://rasmus.axit.local:8554/mjpeg/1 RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.2.1 (LIVE555 Streaming Media v2014.07.25)
RTSP/1.0 200 OK
CSeq: 2
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
DESCRIBE rtsp://rasmus.axit.local:8554/mjpeg/1 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.2.1 (LIVE555 Streaming Media v2014.07.25)
Accept: application/sdp
RTSP/1.0 200 OK
CSeq: 3
Date: Fri, 09 Sep 2016 09:36:29 GMT
Content-Base: rtsp://rasmus.axit.local:8554/mjpeg/1
Content-Type: application/sdp
Content-Length: 91
v=0
o=- -12345678 1 IN IP4 192.168.10.71
s=
t=0 0
m=video 0 RTP/AVP 26
c=IN IP4 0.0.0.0
SETUP rtsp://rasmus.axit.local:8554/mjpeg/1/ RTSP/1.0
CSeq: 4
User-Agent: LibVLC/2.2.1 (LIVE555 Streaming Media v2014.07.25)
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
RTSP/1.0 200 OK
CSeq: 4
Date: Fri, 09 Sep 2016 09:36:29 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Session: -12345678
And VLC:
...
live555 debug: RTP subsession 'video/JPEG'
It doesn't continue from there.
I can't figure out what it's missing. Earlier it didn't send a SETUP either, and that turned out to be a missing empty line on the DESCRIBE response. Consequently I've tried adding various amount of newlines, ids, different dates and what not in different places, but no dice.
Please let me know if you need more information.
Your response to the DESCRIBE commands seems to be invalid - you are replying with 96 characters while the Content-Length header states 91. Not sure if this affects the outcome, but I assume VLC could fail because of this (it could be that it cannot parse the connection data line). Also there seems to be an unneeded extra newline at the end of the SDP data at the end of the last line.
I was trying to setup instant messaging in asterisk server. For the client i'm using Blink Softphone. I did add to my sip.conf
[general]
accept_outofcall_message=yes
outofcall_message_context=dialplan_name
auth_message_requests=yes
and to my extensions.conf
[dialplan_name]
exten => _XXX,1,MessageSend(sip:${EXTEN},"${CALLERID(name)}"${MESSAGE(from)})
So this is a simple extension for testing. But when i try and send the message from user1 to user2 i get in the asterisk log:
[Jan 30 21:17:47] WARNING[6420][C-00000005]: chan_sip.c:10515 process_sdp: Insufficient information in SDP (c=)...
What can be wrong here? I'am sure that the clients are on the nat, so i do have both nat=force_rport,comedia for all my users in sip.conf
My asterisk version is 13 (latest).
[UPDATED]
I turned on the sip debug log, and tried to send the message (first i get some weird retransmission):
Retransmitting #9 (no NAT) to 14.228.14.150:5070: <- weird ip here
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 14.228.14.150:5070;branch=z9hA4cA-abcdef613aca8b1x3124abb0z3e1bc8;received=14.228.14.150;rport=5070
From: 2014<sip:2014#(server_ip_here)>;tag=a312facc
To: 0009735466221178<sip:0009735466221178#(server_ip_here)>;tag=bb62441233
Call-ID: abcdef613aca8b1x3124abb0z3e1bc8
CSeq: 1 INVITE
Server: Asterisk PBX 13.1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="2222abcf"
Content-Length: 0
Then
<--- SIP read from TLS:(my_ip_here):49312 --->
INVITE sip:123#(server_ip_here) SIP/2.0
Via: SIP/2.0/TLS (my_ip_here):49312;rport;branch=b4ae88b115be15a5n9244;alias
Max-Forwards: 70
From: "user1" <sip:user1#server_ip_here>;tag=39e388fd5f616b7
To: <sip:123#(server_ip_here)>
Contact: <sip:12313560#(server_ip_here):49311;transport=tls>
Call-ID: ac48128192za12a2f432e24c18aabc7q
CSeq: 28982 INVITE
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
Supported: 100rel, replaces, norefersub, gruu
User-Agent: Blink 0.9.1.2 (Windows)
Content-Type: application/sdp
Content-Length: 308
v=0
o=- 3211422221 3211422221 IN IP4 (my_ip)
s=Blink 0.9.1.2 (Windows)
t=0 0
m=message 2855 TCP/TLS/MSRP *
c=IN IP4 (my_ip)
a=path:msrps://(my_ip):2855/37a1cc82ab315e21b222;tcp
a=accept-types:message/cpim text/* application/im-iscomposing+xml
a=accept-wrapped-types:*
a=setup:active
<------------->
--- (13 headers 10 lines) ---
Sending to (my_ip):49312 (NAT)
Sending to (my_ip):49312 (NAT)
Using INVITE request as basis request - ad72cd1681aff769721af12c21aaea7c
Found peer 'user1' for 'user1' from (my_ip):49312
== Using SIP VIDEO CoS mark 6
== Using SIP RTP CoS mark 5
[Jan 31 21:02:17] WARNING[27265][C-00000118]: chan_sip.c:10515 process_sdp: Insufficient information in SDP (c=)...
arheops was right! Using INVITE request as basis request <- here it is. Instead of MESSAGE for some reason INVITE request is used.
Looks like your softphone use INVITE instead of MESSAGE for messaging.
You can get more info by enable sip debug in asterisk console
asterisk -r
sip set debug on
Trying to determine if a user actually downloaded an executable file from a website. I examined the pcap and I see that the Content-Length field = 784,536 but the Server->User is 430,380 bytes. This tells me that the user did not fully download the file. I also downloaded the file myself and see that it is 766 KB. Is it possible that the content-length value based on the HTTP header will not be EQUAL TO the file size of that EXE file if it is downloaded (the local file size)? Is this correct?
Packet Capture Data (I can't post screenshots)
GET /ChromasLite211Setup.exe HTTP/1.1
Host: www.technelysium.com.au
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Firefox/17.0
Accept: text/html, application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us
Accept-Enconding: gzip, deflate
Connection: keep-alive
Referrer: http://technelysium.com.au/
HTTP/1.1 200 OK
Date: Thu, 01 Aug 2013 17:28:17 GMT
Server: Apache
Last-Modified: Mon, 15 Apr 2013 08:29:57 GMT
Accept-Ranges: bytes
Content-Length: 784536
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/x-msdownload
MZP........................#.............................!..L..This program must be run under Win32
Entire Conversation (430722 bytes)
Users IP -> Server IP (342 bytes)
Server IP -> Users IP (430380)
When I download the file from the site it shows as, "Binary FIle (766 KB)"
Converting Bytes to Kilobytes
784,536/1024 = 766.14
No. The user did not download all the bytes.
If a server sends a Content-Length header, that is exactly how many bytes of content it intends to send as the HTTP Response Body. If less than that number was sent, then something happened (Client terminated connection, Client timed out, etc.)
I am loading a MP3 stream from IceCast 2.3.2-kh29 server in the Android app with MediaPlayer class.
Playing works well, but sometimes stops happen. If see the server responses in IcyStreamMeta class for ID3 tags, there is 404 error for this case.
Also it happens in Windows 7: Firefox and other browsers.
Here are normal headers (some data ***ed):
http://***:14534/***.mp3
GET /***.mp3 HTTP/1.1
Host: ***:14534
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Tue, 23 Jul 2013 21:22:00 GMT
Content-Type: audio/mpeg
Transfer-Encoding: chunked
Connection: keep-alive
icy-br: 192
ice-audio-info: bitrate=192;samplerate=44100;channels=2
icy-description: MP3 192 Kbps
icy-genre: ***
icy-name: ***
icy-pub: 1
icy-url: ***
Cache-Control: no-cache
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
So, the stream sometimes plays only about a minute or less, sometimes seconds and stops. What's the possible reason of 404 error? In other devices there were tests with stable work. Internet speed is well. Can router cause such things? Also, maybe some special HTTP request headers are needed for IceCast (and if they're not present, it gives 404)? Or it's an internal server error for some cases?
So, from WireShark:
2973 53.630385000 SERVER'S IP 192.168.100.6 TCP 1466 14534 > 59847 [ACK] Seq=1284017 Ack=1 Win=63 Len=1412
2976 53.636352000 SERVER'S IP 192.168.100.6 TCP 1157 14534 > 59847 [PSH, ACK] Seq=1285429 Ack=1 Win=63 Len=1103
2978 53.671606000 SERVER'S IP 192.168.100.6 TCP 60 14534 > 59847 [PSH, ACK] Seq=1286532 Ack=1 Win=63 Len=5
2980 53.678606000 SERVER'S IP 192.168.100.6 TCP 60 14534 > 59847 [FIN, ACK] Seq=1286537 Ack=2 Win=63 Len=0
The issue is your chunked encoding. You're proxying your stream through Nginx, and Nginx is "fixing" the output to be compatible with HTTP/1.0. Don't do that.
You can try turning off chunked encoding in your Nginx config:
chunked_transfer_encoding off
I am using NetStream, NetConnection and Video object to play an mp4 file which is hosted over a web server using http.
The mp4 file URL is for example: http://xx.xx.xx.xx/file.mp4
This is an AIR application and the relevant code is pasted below:
var url:String = <some http url>;
connect_nc = new NetConnection();
connect_nc.connect(null);
stream_ns = new NetStream(connect_nc);
var ns_object:Object = new Object();
ns_object.onPlayStatus = ns_onPlayStatus;
stream_ns.client = ns_object;
videoMP4.attachNetStream(stream_ns);
stream_ns.bufferTime = 1.0 // 1 sec
stream_ns.addEventListener(NetStatusEvent.NET_STATUS, onNetStatusEventHandler);
stream_ns.play(url);
This code works when run on MAC OS X. But it does not work when run on Windows XP. I get the error:
NetStream.Play.StreamNotFound
I also tried playing the URL using VLC player on the same windows XP host. The URL is valid because VLC can play it.
In my particular case, the http URL is hosted by WMP 12 (window media player 12) on Win 7 machine where I am using the media sharing feature of WMP 12.
After further looking into http traffic on wireshark, here is what i found.
After running wireshark on the host running the adobe AIR application, it seems that it is getting a HTTP 406 response from
the server being run by WMP 12.
GET /WMPNSSv4/63903908/1_ezVGREUzQTA4LTdDQzQtNDJFMy1CNDVDLUZEMjA4MDE5OUM4Q30uMC44.mp4 HTTP/1.1
Host: 192.168.0.102:10243
User-Agent: Mozilla/5.0 (Windows; U; en) AppleWebKit/526.9+ (KHTML, like Gecko) AdobeAIR/1.5
Referer: app:/clicker.swf
x-flash-version: 10,0,12,36
Connection: Keep-Alive
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, text/plain;q=0.8, text/css, image/png, image/jpeg, image/gif;q=0.8, application/x-shockwave-flash, video/mp4;q=0.9, flv-application/octet-stream;q=0.8, video/x-flv;q=0.7, audio/mp4, application/futuresplash, */*;q=0.5
Response:
HTTP/1.1 406 Not Acceptable
Last-Modified: Mon, 19 Oct 2009 23:21:14 GMT
Server: Microsoft-HTTPAPI/2.0
Accept-Ranges: bytes
TransferMode.DLNA.ORG: Streaming
Date: Tue, 12 Jan 2010 22:52:48 GMT
Connection: close
Content-Length: 0
On MAC:
It receives 200 OK response though, and that is why the video streaming works.
GET /WMPNSSv4/63903908/1_ezVGREUzQTA4LTdDQzQtNDJFMy1CNDVDLUZEMjA4MDE5OUM4Q30uMC44.m p4 HTTP/1.1
Host: 192.168.0.102:10243
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/526.9+ (KHTML, like Gecko) AdobeAIR/1.5.3
Referer: app:/clicker.swf
X-Flash-Version: 10,0,42,34
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive
Response:
HTTP/1.1 200 OK
Content-Length: 1524867
Content-Type: video/mp4
Last-Modified: Mon, 19 Oct 2009 23:21:14 GMT
Server: Microsoft-HTTPAPI/2.0
Accept-Ranges: bytes
TransferMode.DLNA.ORG: Streaming
Date: Tue, 12 Jan 2010 22:56:20 GMT
The difference that I can see in the HTTP requests between the Windows XP and MAC version is the Accept: Header. Is the Accept: header value wrong for Windows case because of which WMP 12 rejects
the http request.
If i run the adobe AIR application on Win 7 host, i see the same failure.
Am I using the NetStream object incorrectly or it is a bug in WMP 12 code not being able to parse
the header properly or it is a flex bug where it is generating an incorrect accept: header?
I believe WMP 12 incorrectly handles 'Accept' header in a request. If it contains 'q' (quality) parameter, then WMP ignores this mime-type. And if there are no other suitable mime-types for WMP, it will respond with 406 Not Acceptable error.
I encountered this issues when was trying to display DLNA image in Chrome browser.
I used curl utility to send requests with different headers to figure out what goes wrong.
Request that results in 406 Not Acceptable error:
curl -v -o file.jpg -H "Accept: text/html,*/*,q=0.8" "http://127.0.0.1:10243/WMPNSSv4/3065481158/0_e0I5MzA1MTRELUYwMEEtNEQwRC1CQzg4LTg3NEI5QjQ4MDYyM30uMC5C.jpg"
GET /WMPNSSv4/3065481158/0_e0I5MzA1MTRELUYwMEEtNEQwRC1CQzg4LTg3NEI5QjQ4MDYyM30uMC5C.jpg HTTP/1.1
User-Agent: curl/7.31.0
Host: 127.0.0.1:10243
Accept: text/html,*/*;q=0.8
HTTP/1.1 406 Not Acceptable
Last-Modified: Tue, 21 May 2013 21:01:09 GMT
Server: Microsoft-HTTPAPI/2.0
Accept-Ranges: bytes
TransferMode.DLNA.ORG: Interactive
Date: Fri, 30 Aug 2013 09:10:32 GMT
Connection: close
Content-Length: 0
Successful request:
curl -v -o file.jpg -H "Accept: text/html,*/*" "http://127.0.0.1:10243/WMPNSSv4/3065481158/0_e0I5MzA1MTRELUYwMEEtNEQwRC1CQzg4LTg3NEI5QjQ4MDYyM30uMC5C.jpg"
GET /WMPNSSv4/3065481158/0_e0I5MzA1MTRELUYwMEEtNEQwRC1CQzg4LTg3NEI5QjQ4MDYyM30uMC5C.jpg HTTP/1.1
User-Agent: curl/7.31.0
Host: 127.0.0.1:10243
Accept: text/html,*/*
HTTP/1.1 200 OK
Content-Length: 2394679
Content-Type: image/jpeg
Last-Modified: Tue, 21 May 2013 21:01:09 GMT
Server: Microsoft-HTTPAPI/2.0
Accept-Ranges: bytes
TransferMode.DLNA.ORG: Interactive
Date: Fri, 30 Aug 2013 09:10:40 GMT