When Using RtspClient, the library doesn't seem to receive any RTP packets

Topics: Question
Apr 12, 2015 at 7:33 PM
I discovered your library after I purchased some webcams and decided to start tinkering with them. I'm playing with some China brand cameras that stream H264. The actual brand is Wision, and the model is WS-A9R31.

Anyway, I'm sure its something I'm doing wrong, but I'm hoping you can shed some light. I scavenged some code from this forum to setup the library. I create an rtspClient, and am able to get the library to successfully interact with the camera (DESCRIBE, SETUP etc). I register to receive RTPFrameChanged Events as well as RTPPacketReceived events among others. I can see on Wireshark where the video packets are coming in, but the library doesn't seem to react to them.

I used the exact same URL from my test harness with VLC successfully.

I ran a wireshark capture on the VLC session, and then ran a capture on the MMA + test harness.

Any pointers would be appreciated!

And by the way, what a fantastic job of software engineering you have done. This is the first time I have ever read about video protocols etc, but your commenting and decomposition/factoring reminds me of my college days. Thank you for all your time and effort on this. My condolences on Bandit. Unbelievable story...

-F
Coordinator
Apr 12, 2015 at 7:41 PM
Can't really say without a code example in this case as the log shows a TEARDOWN coming from the code... Why that occurs is unknown without such an example.

I would say to run the example from the TestRtspClient using the camera address specified in the dump and to try to verify the results that way, also if you could indicate the change set from source control your working with it would be helpful.

Thanks for the kind words, let me know if you need anything else.
Marked as answer by juliusfriedman on 4/12/2015 at 12:42 PM
Apr 12, 2015 at 8:58 PM
Thanks for your quick reply. I really appreciate you taking the time to help.

I took your suggestion. I downloaded a fresh copy of the library (111212), compiled it. I ran TestRtcpClient with my uri, and credentials, proto=null.

It seems that I am still not receiving any RTP packets. The camera works with VLC pointed to the same URI.

Here is the wireshark capture.
Here is the debug screen log:

Location = "rtsp://192.168.0.200/PSIA/Streaming/channels/h264"
Press a key to continue. Press Q to Skip, Press B to set the buffer size.
    *****************
Connected to :rtsp://192.168.0.200/PSIA/Streaming/channels/h264
    *****************
ConnectionTime:00:00:00.0110000
    *****************
Starting Playback of :rtsp://192.168.0.200/PSIA/Streaming/channels/h264
Client Sent Request :OPTIONS rtsp://192.168.0.200/PSIA/Streaming/channels/h264 R
TSP/1.0
CSeq: 1


Client Received Response :RTSP/1.0 200 OK
CSeq: 1
Date: Wed, Jan 04 2012 02:33:22 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


Client Sent Request :DESCRIBE rtsp://192.168.0.200/PSIA/Streaming/channels/h264
RTSP/1.0
Accept: application/sdp
CSeq: 2


Client Received Response :RTSP/1.0 401 Unauthorized
CSeq: 2
Date: Wed, Jan 04 2012 02:33:22 GMT
WWW-Authenticate: Digest realm="LIVE555 Streaming Media", nonce="3d7309818a9d92
b7b664c513ae523d35"


Client Sent Request :DESCRIBE rtsp://192.168.0.200/PSIA/Streaming/channels/h264
RTSP/1.0
Accept: application/sdp
CSeq: 3
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
3d7309818a9d92b7b664c513ae523d35", uri="rtsp://192.168.0.200/PSIA/Streaming/chan
nels/h264", response="ec8fce6e84983f9efac4c1b605fbf65c"


Client Received Response :RTSP/1.0 200 OK
CSeq: 3
Date: Wed, Jan 04 2012 02:33:22 GMT
Content-Base: rtsp://192.168.0.200/PSIA/Streaming/channels/h264/
Content-Type: application/sdp
Content-Length: 595

v=0
o=- 1325376012161475 1 IN IP4 192.168.0.200
s=RTSP/RTP stream from IPNC
i=h264
t=0 0
a=tool:LIVE555 Streaming Media v2011.05.25
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:RTSP/RTP stream from IPNC
a=x-qt-text-inf:h264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:12000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=Z2QA
KK2EBUViuKxUdCAqKxXFYqOhAVFYrisVHQgKisVxWKjoQFRWK4rFR0ICorFcVio6ECSFITk8nyfk/k/J
8nm5s00IEkKQnJ5Pk/J/J+T5PNzZprQDwBE/LKkAAAMAeAAAHCBgQAAW42AABm/zve+F4RCNQAAAAAE=
,aO48sA==
a=control:track1

Client Sent Request :SETUP rtsp://192.168.0.200/PSIA/Streaming/channels/h264/tra
ck1 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=10000-10001;mode="PLAY"
CSeq: 4
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
74DF7DFF", uri="rtsp://192.168.0.200/PSIA/Streaming/channels/h264/track1", respo
nse="f8e3fdd15616f2fe74abdf1ff498fe86"


Client Received Response :RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Jan 04 2012 02:33:22 GMT
Transport: RTP/AVP;unicast;destination=192.168.0.1;source=192.168.0.200;client_
port=10000-10001;server_port=6970-6971
Session: 60D5715B


Client Sent Request :PLAY rtsp://192.168.0.200/PSIA/Streaming/channels/h264 RTSP
/1.0
Range: npt=now-
CSeq: 5
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
7F5EEF76", uri="rtsp://192.168.0.200/PSIA/Streaming/channels/h264", response="9e
c7e86be2d2a74801c1e2a6b8949776"
Session: 60D5715B


Client Received Response :RTSP/1.0 200 OK
CSeq: 5
Date: Wed, Jan 04 2012 02:33:23 GMT
Session: 60D5715B
RTP-Info: url=rtsp://192.168.0.200/PSIA/Streaming/channels/h264/track1;seq=1360
3;rtptime=1455185317


Media.Rtp.RtpClient-21ca69b6-2125-4fa5-bfd4-684e8c1562a1@SendRecieve - Begin
    *****************Playing from Live Source
    *****************Local Id 1547666878    *****************Remote Id 0
    *****************
StartedListening to :rtsp://192.168.0.200/PSIA/Streaming/channels/h264
Waiting for connection. Press Q to exit
Press K to send KeepAlive
Press D to DisconnectSocket
Press C to Connect
Press A to Attach events for packets
Press E to Detach packet events
Press I to Attach Interleaved events
Press U to Detach Interleaved events
Press P to send a Partial GET_PARAMETER
Press L to RemoveSession
Press X to send Wildcard DESCRIBE.
Client Playing for :00:00:00.0230020
21ca69b6-2125-4fa5-bfd4-684e8c1562a1HandleIncomingRtcpPacket - No Context for pa
cket -1848878810@200
21ca69b6-2125-4fa5-bfd4-684e8c1562a1HandleIncomingRtcpPacket - No Context for pa
cket -1848878810@202
Client Playing for :00:00:02.0231151
Client Playing for :00:00:04.0232301
Client Playing for :00:00:06.0233443
21ca69b6-2125-4fa5-bfd4-684e8c1562a1HandleIncomingRtcpPacket - No Context for pa
cket -1848878810@200
21ca69b6-2125-4fa5-bfd4-684e8c1562a1HandleIncomingRtcpPacket - No Context for pa
cket -1848878810@202
Client Playing for :00:00:08.0234589
Client Playing for :00:00:10.0235733
21ca69b6-2125-4fa5-bfd4-684e8c1562a1HandleIncomingRtcpPacket - No Context for pa
cket -1848878810@200
21ca69b6-2125-4fa5-bfd4-684e8c1562a1HandleIncomingRtcpPacket - No Context for pa
cket -1848878810@202
Client Sent Request :OPTIONS * RTSP/1.0
CSeq: 6
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
155BEDFB", uri="\", response="4f0de31ab647bf6254479b207a2c6432"
Session: 60D5715B


Client Received Response :RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Jan 04 2012 02:33:34 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


Client Received Response :RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Jan 04 2012 02:33:34 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Jan 04 2012 02:33:34 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


Client Sent Request :OPTIONS * RTSP/1.0
CSeq: 7
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
6D57F8B7", uri="\", response="8b9edf52b2dfcaf5bdd799897c735a31"
Session: 60D5715B


Client Received Response :RTSP/1.0 200 OK
CSeq: 7
Date: Wed, Jan 04 2012 02:33:34 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


RTSP/1.0 200 OK
CSeq: 7
Date: Wed, Jan 04 2012 02:33:34 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER
    *****************Stopping All Playback. (Press Q To Exit)
Client Sent Request :TEARDOWN rtsp://192.168.0.200/PSIA/Streaming/channels/h264
RTSP/1.0
Connection: close
CSeq: 8
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
784F7F07", uri="rtsp://192.168.0.200/PSIA/Streaming/channels/h264", response="bb
bc32f7c7fef44a3144dc0ddeb10163"
Session: 60D5715B
    *****************Disconnected from :rtsp://192.168.0.200/PSIA/Streaming/
channels/h264
Sending Requests In Play Success
RTCP Info ▓▓▓▓▓▓▓▓▓▓
RtcpBytes Sent: 192
Rtcp Packets Sent: 11
RtcpBytes Recieved: 0
Rtcp Packets Recieved: 0
RTP Info▓▓▓▓▓▓▓▓▓▓▓▓
Rtp Packets Recieved: 0
Encountered Frames with missing packets: 0
Encountered Empty Frames: 0
Total Frames: 0
Frames still missing packets: 0
RTSP Info▓▓▓▓▓▓▓▓▓▓▓
Rtsp Requests Sent: 8
Rtsp Requests Pushed: 0
Rtsp Requests Retransmitted: 1
Rtsp Responses Receieved: 7
Rtsp Missing : 1
Rtsp Last Message Round Trip Time : 00:00:00.0030001
Rtsp Last Server Delay : -00:00:00.0010000
Rtsp Interleaved: 0
Done. (T) to test again forcing TCP, (U) to test again forcing UDP Press (W) to
run the same test again, Press (Q) or anything else to progress to the next test
.
Coordinator
Apr 12, 2015 at 9:10 PM
Seems the camera is not indicting the ssrc, the camera does provide the sequence number though....

I will take a look into the capture as soon as possible, also try tcp in the meantime.
Marked as answer by juliusfriedman on 4/12/2015 at 2:10 PM
Apr 12, 2015 at 9:22 PM
Thanks!

When I set TCP as the protocol, I get a MethodNotAllowed on the Play Request.

Here is the wireshark capture with TCP as the protocol.

Here is the log:

Location = "rtsp://192.168.0.200/PSIA/Streaming/channels/h264" Using Rtp Protoco
l: Reliable
Press a key to continue. Press Q to Skip, Press B to set the buffer size.
    *****************
Connected to :rtsp://192.168.0.200/PSIA/Streaming/channels/h264
    *****************
ConnectionTime:00:00:00.0109999
    *****************
Starting Playback of :rtsp://192.168.0.200/PSIA/Streaming/channels/h264
Client Sent Request :OPTIONS rtsp://192.168.0.200/PSIA/Streaming/channels/h264 R
TSP/1.0
CSeq: 1


Client Received Response :RTSP/1.0 200 OK
CSeq: 1
Date: Wed, Jan 04 2012 03:00:39 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


Client Sent Request :DESCRIBE rtsp://192.168.0.200/PSIA/Streaming/channels/h264
RTSP/1.0
Accept: application/sdp
CSeq: 2


Client Received Response :RTSP/1.0 401 Unauthorized
CSeq: 2
Date: Wed, Jan 04 2012 03:00:39 GMT
WWW-Authenticate: Digest realm="LIVE555 Streaming Media", nonce="aa4a11d87c6e5c
845ff4b678be27fcdd"


Client Sent Request :DESCRIBE rtsp://192.168.0.200/PSIA/Streaming/channels/h264
RTSP/1.0
Accept: application/sdp
CSeq: 3
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
aa4a11d87c6e5c845ff4b678be27fcdd", uri="rtsp://192.168.0.200/PSIA/Streaming/chan
nels/h264", response="f9d337889430a2de4e3ec6d969c75273"


Client Received Response :RTSP/1.0 200 OK
CSeq: 3
Date: Wed, Jan 04 2012 03:00:39 GMT
Content-Base: rtsp://192.168.0.200/PSIA/Streaming/channels/h264/
Content-Type: application/sdp
Content-Length: 595

v=0
o=- 1325376012161475 1 IN IP4 192.168.0.200
s=RTSP/RTP stream from IPNC
i=h264
t=0 0
a=tool:LIVE555 Streaming Media v2011.05.25
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:RTSP/RTP stream from IPNC
a=x-qt-text-inf:h264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:12000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=Z2QA
KK2EBUViuKxUdCAqKxXFYqOhAVFYrisVHQgKisVxWKjoQFRWK4rFR0ICorFcVio6ECSFITk8nyfk/k/J
8nm5s00IEkKQnJ5Pk/J/J+T5PNzZprQDwBE/LKkAAAMAeAAAHCBgQAAW42AABm/zve+F4RCNQAAAAAE=
,aO48sA==
a=control:track1

Client Sent Request :SETUP rtsp://192.168.0.200/PSIA/Streaming/channels/h264/tra
ck1 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
CSeq: 4
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
5EA5FEFE", uri="rtsp://192.168.0.200/PSIA/Streaming/channels/h264/track1", respo
nse="732d41ff1f57e3717c66d36fe63bb065"


Client Received Response :RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Jan 04 2012 03:00:39 GMT
Transport: RTP/AVP/TCP;unicast;destination=192.168.0.1;source=192.168.0.200;int
erleaved=0-1
Session: 0E817792


Client Sent Request :PLAY rtsp://192.168.0.200/PSIA/Streaming/channels/h264 RTSP
/1.0
Range: npt=now-
CSeq: 5
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
57FE1D96", uri="rtsp://192.168.0.200/PSIA/Streaming/channels/h264", response="0d
37f4b40d80f119dedc6d400ff7b6c6"
Session: 0E817792


Client Received Response :RTSP/1.0 405 MethodNotAllowed
CSeq: 5
Date: Wed, Jan 04 2012 03:00:39 GMT
Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER
    *****************
StartedListening to :rtsp://192.168.0.200/PSIA/Streaming/channels/h264
Waiting for connection. Press Q to exit
Press K to send KeepAlive
Press D to DisconnectSocket
Press C to Connect
Press A to Attach events for packets
Press E to Detach packet events
Press I to Attach Interleaved events
Press U to Detach Interleaved events
Press P to send a Partial GET_PARAMETER
Press L to RemoveSession
Press X to send Wildcard DESCRIBE.
Client Not Playing
Client Not Playing
Client Not Playing
Client Not Playing
Client Not Playing
Client Sent Request :OPTIONS * RTSP/1.0
CSeq: 6
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
2BCF7D77", uri="\", response="7161e82c3fcd5007cbe54602ef327344"
Session: 0E817792


Client Received Response :RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Jan 04 2012 03:00:48 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Jan 04 2012 03:00:48 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


Client Sent Request :OPTIONS * RTSP/1.0
CSeq: 7
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
1FD7FBF5", uri="\", response="ff751b074039dae179e6d23bee0f29da"
Session: 0E817792


Client Received Response :RTSP/1.0 200 OK
CSeq: 7
Date: Wed, Jan 04 2012 03:00:48 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


RTSP/1.0 200 OK
CSeq: 7
Date: Wed, Jan 04 2012 03:00:48 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


Sending Requests In Play Success
RTCP Info ▓▓▓▓▓▓▓▓▓▓
RtcpBytes Sent: 84
Rtcp Packets Sent: 4
RtcpBytes Recieved: 0
Rtcp Packets Recieved: 0
RTP Info▓▓▓▓▓▓▓▓▓▓▓▓
Rtp Packets Recieved: 0
Encountered Frames with missing packets: 0
Encountered Empty Frames: 0
Total Frames: 0
Frames still missing packets: 0
RTSP Info▓▓▓▓▓▓▓▓▓▓▓
Rtsp Requests Sent: 7
Rtsp Requests Pushed: 0
Rtsp Requests Retransmitted: 1
Rtsp Responses Receieved: 7
Rtsp Missing : 0
Rtsp Last Message Round Trip Time : 00:00:00.0010005
Rtsp Last Server Delay : -00:00:00.0010000
Rtsp Interleaved: 0
Done. (T) to test again forcing TCP, (U) to test again forcing UDP Press (W) to
run the same test again, Press (Q) or anything else to progress to the next test
.
Apr 12, 2015 at 9:46 PM
Edited Apr 12, 2015 at 9:47 PM
Is I mentioned earlier, I'm swimming in the shark infested deep water here. I know nothing about video & its protocols other than what I have gleaned through wireshark and your library, so please forgive my ignorance.

Two things I noticed when I first started playing with your library...

(1) MMA requests a "range" during the play command of "now-". I noticed that VLC requests a range of "0.000-". I only bring it up because I notice the response from the camera includes a range on the VLC response, but no range on the MMA response. .Shark Image

(2) Initially, I was stepping through the library trying to get a feel for how it all worked. In the member function TryParseRtpInfo, it failed to parse on occasion instead leaving the int? rtptime as null even though there was a string value in the RtpInfo. I believe it was failing because the string it was trying to parse exceeded the limits of a signed int. I don't know if this is relevant or not, but I thought I would mention it.

-F
Coordinator
Apr 12, 2015 at 10:33 PM
Edited Apr 12, 2015 at 10:36 PM
Technically range "now" is more correct if you want the live stream for various reasons, although looking at the sdp it seems to define an interesting time range.

"0 0"

This is probably causing the Teardown.

If there was a repeat time defined in the sdp I could possibly see how this is supposed to work.

I will double check but the rfc again when I check your latest capture (s).

I will also take a look into the library but again is probably a corner case of an invalid value In the header.

If you could provide a sample of such a case I will definitely check it out.

I will also potentially see about see about allowing indefinite play when the time description is indicated as long as it's allowed per sdp.

Thanks for your input and if you notice anything else in the meantime time let me know.
Marked as answer by juliusfriedman on 4/12/2015 at 3:33 PM
Coordinator
Apr 17, 2015 at 5:15 PM
The file for the capture has since been removed and the picture unfortunately doesn't show all the required information.

Did you still require help or want to have a certain issue addressed?
Apr 19, 2015 at 8:52 PM
Sorry, I thought I posted the capture with 30 day expiration. Weird.

Thanks for helping!

Here is the wireshark capture for MMA-2-Wision

Here is the wireshark capture for VLC-2-Wision

Here is the Console Ouput for the MMA-2-Wision capture:
Location = "rtsp://192.168.0.200/PSIA/Streaming/channels/h264"
Press a key to continue. Press Q to Skip, Press B to set the buffer size.
    *****************
Connected to :rtsp://192.168.0.200/PSIA/Streaming/channels/h264
    *****************
ConnectionTime:00:00:00.0029990
    *****************
Starting Playback of :rtsp://192.168.0.200/PSIA/Streaming/channels/h264
Client Sent Request :OPTIONS rtsp://192.168.0.200/PSIA/Streaming/channels/h264 R
TSP/1.0
CSeq: 1


Client Received Response :RTSP/1.0 200 OK
CSeq: 1
Date: Wed, Jan 11 2012 02:26:53 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SET_PARAMETER


Client Sent Request :DESCRIBE rtsp://192.168.0.200/PSIA/Streaming/channels/h264
RTSP/1.0
Accept: application/sdp
CSeq: 2


Client Received Response :RTSP/1.0 401 Unauthorized
CSeq: 2
Date: Wed, Jan 11 2012 02:26:53 GMT
WWW-Authenticate: Digest realm="LIVE555 Streaming Media", nonce="7e3c1cca01ff82
63e222fa8936e060ab"


Client Sent Request :DESCRIBE rtsp://192.168.0.200/PSIA/Streaming/channels/h264
RTSP/1.0
Accept: application/sdp
CSeq: 3
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
7e3c1cca01ff8263e222fa8936e060ab", uri="rtsp://192.168.0.200/PSIA/Streaming/chan
nels/h264", response="808a1a434bd2619d595bdbfda8ba8641"


Client Received Response :RTSP/1.0 200 OK
CSeq: 3
Date: Wed, Jan 11 2012 02:26:53 GMT
Content-Base: rtsp://192.168.0.200/PSIA/Streaming/channels/h264/
Content-Type: application/sdp
Content-Length: 595

v=0
o=- 1325376012161475 1 IN IP4 192.168.0.200
s=RTSP/RTP stream from IPNC
i=h264
t=0 0
a=tool:LIVE555 Streaming Media v2011.05.25
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:RTSP/RTP stream from IPNC
a=x-qt-text-inf:h264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:12000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=Z2QA
KK2EBUViuKxUdCAqKxXFYqOhAVFYrisVHQgKisVxWKjoQFRWK4rFR0ICorFcVio6ECSFITk8nyfk/k/J
8nm5s00IEkKQnJ5Pk/J/J+T5PNzZprQDwBE/LKkAAAMAeAAAHCBgQAAW42AABm/zve+F4RCNQAAAAAE=
,aO48sA==
a=control:track1

Client Sent Request :SETUP rtsp://192.168.0.200/PSIA/Streaming/channels/h264/tra
ck1 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=10000-10001;mode="PLAY"
CSeq: 4
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
45FDE1BB", uri="rtsp://192.168.0.200/PSIA/Streaming/channels/h264/track1", respo
nse="5505cd839acc59f12efc372f92f68d93"


Client Received Response :RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Jan 11 2012 02:26:53 GMT
Transport: RTP/AVP;unicast;destination=192.168.0.1;source=192.168.0.200;client_
port=10000-10001;server_port=6970-6971
Session: 0E0B1A0B


Client Sent Request :PLAY rtsp://192.168.0.200/PSIA/Streaming/channels/h264 RTSP
/1.0
Range: npt=now-
CSeq: 5
Authorization: Digest username="admin", realm="LIVE555 Streaming Media", nonce="
4D9FDA5F", uri="rtsp://192.168.0.200/PSIA/Streaming/channels/h264", response="7b
00823f3b8fe31957b602cc63fab1e6"
Session: 0E0B1A0B


Client Received Response :RTSP/1.0 200 OK
CSeq: 5
Date: Wed, Jan 11 2012 02:26:53 GMT
Session: 0E0B1A0B
RTP-Info: url=rtsp://192.168.0.200/PSIA/Streaming/channels/h264/track1;seq=3177
8;rtptime=17567053


Media.Rtp.RtpClient-a70ead18-4c98-49d9-9f9f-dd7682242d6d@SendRecieve - Begin
    *****************Playing from Live Source
    *****************Local Id -429643332    *****************Remote Id 0
    *****************
StartedListening to :rtsp://192.168.0.200/PSIA/Streaming/channels/h264
Waiting for connection. Press Q to exit
Press K to send KeepAlive
Press D to DisconnectSocket
Press C to Connect
Press A to Attach events for packets
Press E to Detach packet events
Press I to Attach Interleaved events
Press U to Detach Interleaved events
Press P to send a Partial GET_PARAMETER
Press L to RemoveSession
Press X to send Wildcard DESCRIBE.
Client Playing for :00:00:00.0110107
Client Playing for :00:00:02.0111257
a70ead18-4c98-49d9-9f9f-dd7682242d6dHandleIncomingRtcpPacket - No Context for pa
cket -1848878810@200
a70ead18-4c98-49d9-9f9f-dd7682242d6dHandleIncomingRtcpPacket - No Context for pa
cket -1848878810@202
Client Playing for :00:00:04.0112397
Client Playing for :00:00:06.0113541
a70ead18-4c98-49d9-9f9f-dd7682242d6dHandleIncomingRtcpPacket - No Context for pa
cket -1848878810@200
a70ead18-4c98-49d9-9f9f-dd7682242d6dHandleIncomingRtcpPacket - No Context for pa
cket -1848878810@202
Client Playing for :00:00:08.0114679
Client Playing for :00:00:10.0115833
a70ead18-4c98-49d9-9f9f-dd7682242d6dHandleIncomingRtcpPacket - No Context for pa
cket -1848878810@200
a70ead18-4c98-49d9-9f9f-dd7682242d6dHandleIncomingRtcpPacket - No Context for pa
cket -1848878810@202
Client Playing for :00:00:12.0116978
Client Playing for :00:00:14.0118122
a70ead18-4c98-49d9-9f9f-dd7682242d6dHandleIncomingRtcpPacket - No Context for pa
cket -1848878810@200
a70ead18-4c98-49d9-9f9f-dd7682242d6dHandleIncomingRtcpPacket - No Context for pa
cket -1848878810@202
Client Playing for :00:00:16.0119270
Media.Rtsp.RtspClient-c53a2b03-818c-4a2c-a136-5e98b11641f7@SendRtspMessage: An e
stablished connection was aborted by the software in your host machine

Media.Rtsp.RtspClient-c53a2b03-818c-4a2c-a136-5e98b11641f7@SendRtspMessage: An e
stablished connection was aborted by the software in your host machine
    *****************Stopping All Playback. (Press Q To Exit)
    *****************Disconnected from :rtsp://192.168.0.200/PSIA/Streaming/
channels/h264
Sending In Play Failed
at Media.Common.Extensions.Exception.ExceptionExtensions.Raise[T](TaggedExcep
tion1 exception) in c:\Projects\MMA2\Common\Extensions\ExceptionExtensions.cs:l
ine 70
at Media.Common.Extensions.Exception.ExceptionExtensions.RaiseTaggedException
[T](T tag, String message, Exception innerException) in c:\Projects\MMA2\Common\
Extensions\ExceptionExtensions.cs:line 120
at Media.UnitTests.Program.TestRtspClient(String location, NetworkCredential
cred, Nullable
1 protocol) in c:\Projects\MMA2\Tests\Program.cs:line 1392
RTCP Info ▓▓▓▓▓▓▓▓▓▓
RtcpBytes Sent: 224
Rtcp Packets Sent: 13
RtcpBytes Recieved: 0
Rtcp Packets Recieved: 0
RTP Info▓▓▓▓▓▓▓▓▓▓▓▓
Rtp Packets Recieved: 0
Encountered Frames with missing packets: 0
Encountered Empty Frames: 0
Total Frames: 0
Frames still missing packets: 0
RTSP Info▓▓▓▓▓▓▓▓▓▓▓
Rtsp Requests Sent: 5
Rtsp Requests Pushed: 0
Rtsp Requests Retransmitted: 1
Rtsp Responses Receieved: 5
Rtsp Missing : 0
Rtsp Last Message Round Trip Time : 00:00:00.0029993
Rtsp Last Server Delay : -00:00:00.0010000
Rtsp Interleaved: 0
Done. (T) to test again forcing TCP, (U) to test again forcing UDP Press (W) to
run the same test again, Press (Q) or anything else to progress to the next test
.
Coordinator
Apr 20, 2015 at 2:07 AM
Can you run the test with MMA one more time and attach events with "A" so that I can see the traffic also please?

The RtpClient should have updated the ssrc even though the server didn't send it because the packets were in sequence and with the correct payload type.

Why that didn't occur I would need to look into further.

If you can open the camera for testing you can find my email in the license and I will try to replicate it and resolve the issue if required.

If not I will try from the dumps and the logs, sorry for any inconvenience.
Marked as answer by juliusfriedman on 4/19/2015 at 7:07 PM
Coordinator
Apr 20, 2015 at 11:53 PM
Edited Apr 20, 2015 at 11:54 PM
I replied via email.

In the end I would just like to say thanks for your interest in the library!

To summarize, the issues seems connection related at this time but without further information its' hard to say. The library is working fine and packet events are fired and the client stays connected even when VLC and other clients will not due to the way my client is engineered.

As a result you may get events for packets which you do not need but this is no way effects operation and is desired in some cases.

If you need anything further please definitely let me know!
Marked as answer by juliusfriedman on 4/20/2015 at 4:53 PM
Apr 21, 2015 at 5:32 PM
Thanks Julius for everything.

I have a theory for what is going on in my particular case.

Here was my network topology when I first was having my issue.

Router/Wireless Gateway (LAN Side: 192.168.1.XXX)
      |
      |
 Workstation (WIFI Connection to Router/Wireless Gateway: 192.168.1.100)
                      (Nic @ 192.168.0.100)
                                 |
                                 |
                         POE SWITCH
                                 |
                            Camera (192.168.0.200)

To open the camera to you, I had to move the camera onto the 192.168.1.XXX subnet and voila everything started working.

My theory is that in my original configuration, even though the library is connecting to the camera on the 192.168.0.XXX nic/subnet, it is opening & listening on the RTPClient context socket on 192.168.1.100, and I never set the machine up to bridge packets. Assuming I'm correct, shouldn't the library listen on the same interface that the whole RTSP communication started on?
Coordinator
Apr 21, 2015 at 8:05 PM
It depends on the underlying networking configuration.

I have a few updates pending which make it easier to determine which Network Interface has what IP Address bound and what route to what host the connection is taking however these aren't very useful except in certain advanced configurations.

I am not sure what your question is, you can definitely send traffic out of one interface which is bound for another, receiving could also be implemented.

How you are handling NAT I do not know, your diagram is helpful but doesn't really give me any insight on your question or how I can answer it.

With that being said if you need anything else definitely let me know!
Marked as answer by juliusfriedman on 4/21/2015 at 1:05 PM
Apr 22, 2015 at 5:40 AM
Edited Apr 22, 2015 at 5:41 AM
Let me rephrase my question.

In my particular case, I have two network connections to my computer.
(1) Primary interface was in 192.168.1.XXX segment.
(2) Secondary interface was in 192.168.0.XXX segment.

The primary segment has a gateway, and is NAT'ed to the outside world.
The secondary interface is connected to a switch that has nothing but IP Cameras on it. The secondary network has no gateway setup. There is no way for clients on the secondary network to route packets outside of its subnet (255.255.255.0). It is a completely isolated internal private network.

My theory for what is happenning is that I think in my particular case that even though the RTSP conversation is occurring on the secondary interface exclusively, when the RTSP conversation tries to setup the RTP connection, my computer & the library starts listening on the primary interface for RTP traffic (instead of the secondary interface where all the other RTSP conversation was going on).

Forgive my ignorance, but it seems logical to me that by default, the library would choose to listen for the RTP traffic on the same network interface that the RTSP conversation is going on, instead of assuming that the RTP conversation is going to occur on the primary interface. If I am correct, MMA is listening on the primary interface where it can't possibly receive a packet that originates on the secondary network.

Also, assuming my theory is correct as to what is happening, but my suggestion of listening on the same interface that the RTSP traffic was on by default isn't logical, how would I go about telling the library to listen on my secondary interface in this particular case?
Coordinator
Apr 22, 2015 at 6:04 AM
Your theory is unrealized.

It sounds like your in need of something but I don't know what...

It's incorrect mma uses a default interface, it uses the first interface available depending on the address family of the resolved host.

Those functions are also hastily written and of limited use as indicated in the code and above and I already stated that I have updates which can use specific adapters when required but so can you... that's technically outside the scope of mma, how would you do the same with HttpWebRequest??


You can also handle this with routing and techniques such as bridging...

I need a specific question to give a specific answer...
Marked as answer by juliusfriedman on 4/21/2015 at 11:04 PM
May 1, 2015 at 5:21 AM
Edited May 1, 2015 at 5:23 AM
Well, I finally figured out what is going on, and I thought it only fair that I report back in case my ignorance of networking impacts someone else.

On the machine that I was tinkering on, I have a WIFI link to the outside world.

To start tinkering with the cameras, I enabled one of the NICs in my machine, connected a POE switch, created a new ip subnet and hooked up my cameras. Everything seemed to work just nifty except that I was receiving no RTP packets in the library, even though Wireshark showed them coming in.

Then, when Julius asked me to open the camera for him, I moved the camera onto the network segment that my WIFI connection was part of (no longer part of the private POE switch network). Everything worked perfectly for Julius as you will see above. Packets were coming in no problem etc.

What really threw me for a loop is that VLC connects to the camera without any issues regardless of whether it is on the WIFI/LAN network segment, or the mini wired network segment that is on my desktop. On the other hand, the library only received RTP packets on one of the two networks connected to my machine.

My network is multi-homed.

So, i decided that it must have something to do with how the network stack was handling the incoming packets so I checked the routing table and saw the broadcast routes as below....(From Memory)


IPv4 Route Table
Active Routes

Network Destination Netmask Gateway Interface Metric

    224.0.0.0        240.0.0.0         On-link       127.0.0.1                  306
    224.0.0.0        240.0.0.0         On-link       192.168.2.2              266
    224.0.0.0        240.0.0.0         On-link       192.168.1.136          284


I was receiving RTP packets from cameras on the 192.168.2.XXX network, but not from the 192.168.1.XXX network. So I forced the metric on the 192.168.1.XXX to be lower than the other network, and voila, I started receiving RTP packets on the 192.168.1.XXX network.

Once again, forgive me for wasting your time with my ignorance, but I hope you can answer another question for me. Clearly it is possible to receive broadcast packets on both the interfaces without messing with the routing tables because the VLC client worked on both network segments out of the box. What do I need to do to make the MMA library work with two cameras on different segments in a multi-homed network? Is it a network configuration issue as you alluded to in an earlier response, or do I need to issue some network commands in code ?

Thanks for all your help!
Frank
Coordinator
May 1, 2015 at 5:44 AM
I appreciate your well written and seemingly correct explanation therein.

I think you would benefit from finding the answer yourself in this case and optionally documenting and explaining your results.

Thank you again for your interest in the library.
Marked as answer by juliusfriedman on 4/30/2015 at 10:44 PM
May 1, 2015 at 5:25 PM
I'm kind of lost. Perhaps you can point me in the right direction.

From what I can tell, it seems that the packets are going from the camera to the OS network stack, but the OS stack isn't passing the packets on to .NET socket implementation and from there to MMA. I say this because I can see the packets on the Wire, but when I enable .NET's tracing of the .NET network code, the packets aren't showing up in the trace.

Reading between the lines of your replies, I would guess that you are suggesting its a network configuration error. That would make sense since I was able to see the packets when I changed the metric on the intranet interface. The thing that throws me off here, is why would VLC work with no modification to my routing tables?

Perhaps you can get me started down the right path?

Thanks,
Frank
Coordinator
May 1, 2015 at 5:46 PM
Edited May 1, 2015 at 5:47 PM
AFAIK, your on the right path.

I think you question is about ffmpeg and not my library.

Vlc uses ffmpeg as well as live and other libraries.

You can check out how connections are created in ffmpeg and how they are utilized by reviewing their source code.

You can also contact ASTI to explain your needs and we maybe already have something you can use for this.

Sincerely
Marked as answer by juliusfriedman on 5/1/2015 at 10:46 AM