Hi Ross,
Thanks for the earlier reply.
Can you please examine my following observation and provide your kind feedback
on this.
our server is a public server and for this I am using testRTSPClient on my
local machine. I observed the RTCP packets on wireshark at both client and
server end. What i saw is that when the Receiver reports are sent from the
client, the destination IP shown in 'wireshark on client side' is the public IP
of the server and the RTCP RR and SR reports work perfectly fine in this case.
But when using UDP, the destination IP for RR shown in 'wireshark on client
end' is the private IP of the server and the receiver packets are not reaching
to the Server in this case. To confirm that this may be the cause, I just hack
the client code in udp case and passed the public IP hard coded in
MediaSubsession::setDestinations method. Now I can see in Wireshark that the
destination IP for the Receiver Reports is the public IP of the server which i
hardcoded. and now on the server I am receiving the receiver reports on the
server and everything works fine. What is this behavior and how can I fix it?
Best Regards
Mohsin
________________________________________
From: live-devel <live-devel-boun...@ns.live555.com> on behalf of Ross
Finlayson <finlay...@live555.com>
Sent: Tuesday, November 3, 2015 11:28 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] RTCP RR reports do not reach to the server using
UDP
> But we are having problem with UDP (REQUEST_STREAMING_OVER_TCP false) . First
> issue was that SR reports were sent by the server but were not reaching the
> client. the wireshark on the server shows the ICMP destination unreacheable
> (port unreachable) message from the client in response to SR reports. For
> testing purpose we fixed it with enabling port forwarding on our router. and
> now SR Reports reach to the client and there is no ICMP response. but now the
> problem is that RR reports are not reaching to the Server. What would be the
> possible cause for this?
The same thing. You have a ‘middlebox’ somewhere between your client and your
server that is either blocking these RTCP “RR” packets (from the client) from
reaching the server.
To see what UDP ports are involved, look at the response to the RTSP “SETUP”
command. (If your stream contains both an audio track and a video track, then
there will be one of these for each track.) For example, if response to a
“SETUP command is:
RTSP/1.0 200 OK
CSeq: 4
Date: Tue, Nov 03 2015 22:15:51 GMT
Transport:
RTP/AVP;unicast;destination=133.93.96.43;source=4.79.217.242;client_port=51384-51385;server_port=6970-6971
Session: E3F2FB49;timeout=65
then:
- RTP packets (from the server to the client) will be sent from port
6970 to port 51384
- RTCP “SR” packets (from the server to the client) will be sent from
port 6971 to port 51385
- RTCP “RR” packets (from the client to the server) will be sent from
port 51385 to port 6971
Note that RTSP/RTP cannot be expected to work if you have NAT (Network Address
and/or Port Translation) happening between your client and server. I.e., your
client and server should be sharing the same address/port space. However, if
your ‘middlebox’ is only a firewall - not a NAT - then you should be able to
get it to work by unblocking appropriate UDP ports.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
