I know similar questions have been asked but I have not been able to find the answer to my SPECIFIC problem.
I am attempting to create a RTSP/RTP video stream from the Android camera to a VLC Player client. I have written a small RTSP server to handle all the the setup and VLC seems to like my parameters. However, after the PLAY command is issued and My app starts sending the video stream (via DatagramPackets) the VLC player does not receive any data.
I am using the jlibrtp library and setup my stream like this
sendSoc = new DatagramSocket(1238);
recSoc = new DatagramSocket(1239);
sess = new RTPSession(sendSoc, recSoc);
FakeClass fc = new FakeClass(); //This implements the RTPAppIntf but all the functions are empty
sess.RTPSessionRegister(fc, null, null);
sess.payloadType(96);
Participant p = new Participant("localhost",1236,1237);
sess.addParticipant(p);
This is the logs I see from VLC player
Opening connection to 192.168.1.221, port 1234...
[0xb1003790] main art finder debug: no art finder module matching "any" could be loaded
[0xb1003790] main art finder debug: TIMER module_need() : 6.331 ms - Total 6.331 ms / 1 intvls (Avg 6.331 ms)
[0x9f653e0] main playlist debug: art not found for rtsp://192.168.1.221:1234
...remote connection opened
Sending request: OPTIONS rtsp://192.168.1.221:1234 RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23)
Received 76 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 2
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Sending request: DESCRIBE rtsp://192.168.1.221:1234 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23)
Accept: application/sdp
Received 240 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
CSeq: 3
Content-Type: application/sdp
v=0
o=- 1343306778867 1343306778867 IN IP4 192.168.1.221
s=Droid Stream
i=Live Stream from Android Camera
t=1343306778873 0
m=video 1236/2 RTP/AVP 96
a=rtpmap:96 H264/9000
[0xb0101190] live555 demux debug: RTP subsession 'video/H264'
Sending request: SETUP rtsp://192.168.1.221:1234/ RTSP/1.0
CSeq: 4
User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23)
Transport: RTP/AVP;unicast;client_port=1236-1237
Received 128 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 4
Session: 1343306779273
Transport: RTP/AVP/UDP;unicast;client_port=1236-1237;server_port=1238-1239
[0xb5203c18] main input debug: selecting program id=0
[0xb0101190] live555 demux debug: setup start: 0.000000 stop:0.000000
Sending request: PLAY rtsp://192.168.1.221:1234 RTSP/1.0
CSeq: 5
User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23)
Session: 1343306779273
Range: npt=0.000-
Received 71 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 5
Session: 1343306779273
Range: npt=0.000-
.
.
[Snip]
.
.
[0xb5203c18] main input debug: `rtsp://192.168.1.221:1234' successfully opened
[0xb0101190] live555 demux warning: no data received in 10s. Switching to TCP
Sending request: TEARDOWN rtsp://192.168.1.221:1234 RTSP/1.0
CSeq: 6
User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23)
Session: 1343306779273
So I don't know what is wrong. VLC should be listening on the android device port 1236 but its not seeing the packets so i dont know where it is listening. Can tell me if this looks right?
Found out the issue was writing my packets to the Android device port 1236 instead of the client device port 1236. So the transport parameter in the SETUP command that states
Transport: RTP/AVP/UDP;unicast;client_port=1236-1237;server_port=1238-1239
Is stating the server (Android phone) will send RTP packets from server port 1238 to client device port 1236. Likewise, RTCP communication will occur between server port 1239 and client device port 1237.
Didn't you try to check session? Does it contain packets on port 1236? Is it possible that your FakeClass must contain any functions which must send data to VLC?
Related
I am working on a Wifi Display Sink application in android and am facing an issue where the source is not sending the UDP server-port number in the RTSP SETUP message.
The SETUP RESPONSE is as below
'RTSP/1.0 200 OK
cseq: 2
date: Tue, 11 Aug 2015 15:12:38 +0000
server: Mine/1.0
session: 1719935144;timeout=60
transport: RTP/AVP/UDP;unicast;client_port=15550-15551;
'
NOTE:
I have figured out the server-port number using tcpdump in the source device. It is 16660. It doesnot look like any specifically assigned port number as well.Seems like a random port number hardcoded into the source device for Wifi Display Application.
Is there any other way to know the server-port number to which I should listen to for incoming UDP packets?
You should be listening on port 15550 and 15551 and the incoming UDP packets will contain their source port.
I have downloaded nfcpy and successfully ran the beam examples.
I use the beam.py to send data from a RPi with PN532 NFC chip to a Nexus Android phone, the data is sent correctly but on the RPi the python script does not exist as long as I keep the phone next to the reader.
The question applies to sending and receiving from nfcpy.
What do I have to do for the beam.py to exist
safely ?
Example:
Sending:
./beam.py --device tty:AMA0:pn53x send ndef start.ndef
[nfc.clf] searching for reader with path 'tty:AMA0:pn53x'
[nfc.clf] using NXP PN532 at /dev/ttyAMA0
[nfc.snep.server] snep server bound to port 4 (MIU=1984, RW=15), will accept up to 1048576 byte NDEF messages
[nfc.dev.pn53x] activated as target in 424 kbps active mode
[nfc.dev.pn53x] [Errno 110] Connection timed out
[nfc.dev.pn53x] activated a p2p target in 424 kbps active mode
[nfc.llcp.llc] LLCP Link established as NFC-DEP Initiator
Local LLCP Settings
LLCP Version: 1.1
Link Timeout: 500 ms
Max Inf Unit: 2175 octet
Service List: 0000000000010011
Remote LLCP Settings
LLCP Version: 1.1
Link Timeout: 1500 ms
Max Inf Unit: 128 octet
Service List: 0000000000010011
[nfc.dev.pn53x] [PN53x Error 0x13] Format error during RF communication
Receiving:
./beam.py --device tty:AMA0:pn53x recv print
[nfc.clf] searching for reader with path 'tty:AMA0:pn53x'
[nfc.clf] using NXP PN532 at /dev/ttyAMA0
[nfc.snep.server] snep server bound to port 4 (MIU=1984, RW=15), will accept up to 1048576 byte NDEF messages
[nfc.dev.pn53x] activated as target in 424 kbps active mode
[nfc.dev.pn53x] [Errno 110] Connection timed out
[nfc.dev.pn53x] activated a p2p target in 424 kbps active mode
[nfc.llcp.llc] LLCP Link established as NFC-DEP Initiator
Local LLCP Settings
LLCP Version: 1.1
Link Timeout: 500 ms
Max Inf Unit: 2175 octet
Service List: 0000000000010011
Remote LLCP Settings
LLCP Version: 1.1
Link Timeout: 1500 ms
Max Inf Unit: 128 octet
Service List: 0000000000010011
[nfc.llcp.tco] accepting CONNECT from SAP 32
[nfc.snep.server] serving snep client on remote sap 32
[main] default snep server got put request
[main] print ndef message 'application/com.example.android.beam'
record 1
type = 'application/com.example.android.beam'
name = ''
data = 'Beam me up!\n\nBeam Time: 15:11:22\n'
record 2
type = 'urn:nfc:ext:android.com:pkg'
name = ''
data = 'com.example.android.beam'
[nfc.dev.pn53x] [PN53x Error 0x13] Format error during RF communication
The most natural way that an NFC P2P link terminates is with some error caused by link disruption. For as long as both devices are in proximity, the communication will just continue with exchange of symmetry packets. This way either device may start other conversations as it wishes - SNEP (or beam) is not just the only thing.
Specifically for nfcpy's beam example, the way to terminate earlier is by Ctrl-C. Or to modify the example to terminate when the task is done.
I am facing a strange problem when using the standard Android SIP Demo in combination with an asterisk 1.8.9.2 server: incoming / outgoing calls are working correctly, but there is one thing not working: when I launch a call from the SIP demo and I close the call again (hitting the "End current call" button), the call is terminated in the SIP demo, but the called device still keeps ringing.
I have tried to check what's happening by logging the telegrams via Wireshark and it seems that the CANCEL telegram from the SIP demo to the asterisk server is not accepted, take a look:
300 08:30:39.483913 130.10.0.102 192.168.0.110 SIP/SDP 916 Request: INVITE sip:110#192.168.0.110:5060, with session description
301 08:30:39.488686 192.168.0.110 130.10.0.102 SIP 525 Status: 100 Trying
302 08:30:39.524884 192.168.0.110 130.10.0.102 SIP 541 Status: 180 Ringing
309 08:30:41.041071 130.10.0.102 192.168.0.110 SIP 370 Request: CANCEL sip:110#192.168.0.110:5060
310 08:30:41.051545 192.168.0.110 130.10.0.102 SIP 526 Status: 481 Call/Transaction Does Not Exist
And now the real strange thing: If I repeat the same action, and before terminating the call through the "End current call" button I wait for ca. 7 seconds, the CANCEL is accepted and the call is terminated correctly:
646 08:31:05.571464 130.10.0.102 192.168.0.110 SIP/SDP 916 Request: INVITE sip:110#192.168.0.110:5060, with session description
647 08:31:05.576150 192.168.0.110 130.10.0.102 SIP 525 Status: 100 Trying
648 08:31:05.662345 192.168.0.110 130.10.0.102 SIP 541 Status: 180 Ringing
664 08:31:08.302561 130.10.0.102 192.168.0.110 SIP 389 Request: OPTIONS sip:192.168.0.110
665 08:31:08.312097 192.168.0.110 130.10.0.102 SIP 528 Status: 404 Not Found
698 08:31:13.370346 130.10.0.102 192.168.0.110 SIP 370 Request: CANCEL sip:110#192.168.0.110:5060
699 08:31:13.373570 192.168.0.110 130.10.0.102 SIP 513 Status: 487 Request Terminated
700 08:31:13.373912 192.168.0.110 130.10.0.102 SIP 497 Status: 200 OK
I have checked the contents of both CANCEL requests, and the structure is completely the same!
Furthermore I have also tested a server with asterisk 1.6 and there I did NOT encounter this problem, the call is terminated correctly there!
So it makes me believe that it has to do something with asterisk vers. 1.8.
Did anyone encounter similar problems and has some helpful hints for me? If further data is needed for analysis, just let me know!
Thanks for your help,
BR
Armin
I was facing exactly same problem with Asterisk 1.8.11.0 and Android 2.3/4.0.3.
There is a simple solution for this problem under the 'general' section of sip.conf file
add following attribute with value equals to no.
[general]
.
.
pedantic=no
I hope it will also work for you.....
The SIP demo is just a demo :) It may not handle all situations correctly. Does it work with a 'real' SIP client? Use your favorite softphone app to verify. For Android, you can try SIPDroid. If it does, there is something missing from the SIP demo, if not, might be a problem with your Asterisk configuration.
Unfortuntely SIPDroid uses another SIP stack then Gingerbread has installed natively. This is why you don't observe ignoring CANCEL method there. I was playing with android SIP stack for sample integration with AVSystem TR-069 ACS server and had the same observation. Don't know yet whether there is any fix for that. Track progress here: http://avsystem.com
I use own local server as data source for Android MediaPlayer object. When the player connects to the server in first time he sent GET request like this:
GET/ HTTP/1.1
Host: localhost:53087
User-Agent: stagefright/1.1 (Linux;Android 3.2.1)
After for reconnection I recreate the player, but on connection he sends some another request:
GET HTTP/1.1
Host: localhost:53087
Accept: */*
and drops the connection when takes a data immediately. After he sent a request as in the first time and starts playing.
Whats is the reason for so strange behavior?
Android will play both the audio and video (AAC,h263) that I server it from my rtp server, but when I serve an AAC/H264 stream, I only get the audio and no video.
In the working scenario, Android issues a SETUP command for both track ids, but the H264, android never issues the SETUP command for the second Video track.
Is my SDP file correct? The profile-id and sprops I believe are correct as are copied directly from the sps and pps NALs from the H264 encoder. The video is baseline#2.1
Is Android failing to repsond or recognise the second track?
If I stream the video file by itself with live555 it works fine, and I have compared the SDP file it produces with my own one.
Any ideas?
Thanks
H264/AAC SDP file:
v=0
o=xxx IN IP4 192.168.13.43
s=live.3gp
u=http:///
e=admin#
c=IN IP4 0.0.0.0
b=AS:187
t=0 0
a=control:rtsp://192.168.13.43:555/live.3gp
a=isma-compliance:1,1.0,1
a=range:npt=0- 2630.336000
m=audio 0 RTP/AVP 97
a=rtpmap:97 MP4A-LATM/44100/2
a=control:rtsp://192.168.13.43:555/live.3gp/trackID=1
a=fmtp:97 profile-level-id=41; cpresent=0; config=400024203fc0
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:rtsp://192.168.13.43:555/live.3gp/trackID=2
a=cliprect:0,0,256,432
a=framesize:96 432-256
a=fmtp:96 packetization-mode=1; profile-level-id=42C015;sprop-parameter- sets=Njc0MkMwMTVGNDBEODQzNjAyMjAwMDAwMDMwMDIwMDAwMDAzMDNDMUUzMDY1NA==,NjhDRTA0NzI=
SDP file produced by live555 for the same video file which does display on Android:
v=0
o=- 1303401850159891 1 IN IP4 192.168.13.58
s=H.264 Video, streamed by the LIVE555 Media Server
i=live.3g
t=0 0
a=tool:LIVE555 Streaming Media v2011.01.19
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server
a=x-qt-text-inf:baseCasterCap.264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:500
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42C015;sprop-parameter-sets=Z0LAFfQNhDYCIAAAAwAgAAADA8HjBlQ=,aM4Ecg==
a=control:track1
sprop-parameter-sets shouldn't have a tab or space in it (may be a copy/paste bug).
Android (or the player being used there) may not support packetization-mode 1. 0 is required; 1 is optional.
a=framesize and a=cliprect - those aren't standard H.264, but may not be a problem.
I assume the port 0 is normal for your usage (since audio works)? In offer-answer, port 0 would be a rejected stream (in an answer; in an offer it means a disabled stream).
I've seen implementations (I'm looking at YOU, Grandstream!) that insist on spaces after semi-colons for H264 fmtp (they're wrong) - you have a mixture.
Is the "C0" in the profile-level-id correct? that adds constraints; try it without the constraints and see what the response is. (You can still send a more-constrained stream than the SDP indicated.)
Thanks for your help Jesup, it was very much appreciated.
The problem was the sprop parameters, I noticed when I copy and pasted the second SDP file for you.
The encoder I used to do the base64 calculation for my testing was for character data, not binary data. So 65 was being interpreted as the character 6, and the character 5, and encoded, rather than the single number (A in ascii I guess).
Does that make sense?
Silly mistake on my part. Thanks again
Ian