[Bug 654464] udpsrc conflict with rtsp and multicast due to two-phase setup

Wed Jul 13 05:04:10 PDT 2011

https://bugzilla.gnome.org/show_bug.cgi?id=654464
  GStreamer | gst-plugins-good | 0.10.29

--- Comment #4 from Marc Leeman <marc.leeman at gmail.com> 2011-07-13 12:04:03 UTC ---
You are right; the port range is not really needed; the problem still remains.

In essence; I think that the encoder is doing something wrong in the SETUP
phase (not suggesting the correct ports, but just replying with Not Found); but
we get there due to attempt to setup unicast ports on our side; while we know
it should be multicast since the SDP told us already.

I have two encoders of the same make; encoder A and encoder B. Encoder A seems
to be a slightly more recent version wrt to encoder B. Starting A before B
triggers the issue; while starting B before A does not (encoder A corrects the
ports in the SETUP reply).

No doubt that this is wrong by the encoder B; this is what encoder B sends me
after I started encoder A:

RTSP request message 0x7fffbe970ab0
 request line:
   method: 'SETUP'
   uri:    'rtsp://10.3.0.171:7070/track1'
   version: '1.0'
 headers:
   key: 'Transport', value: 'RTP/AVP;multicast;client_port=5004-5005'
 body:
RTSP response message 0x7fffbe970a70
 status line:
   code:   '404'
   reason: 'Stream Not Found'
   version: '1.0'
 headers:
   key: 'CSeq', value: '3'
   key: 'Date', value: 'Wed, Jul 13 2011 11:40:27 GMT'
 body: length 0

This is what another encoder (more recent of the same make) sends me after I
started encoder A before B.

RTSP request message 0x7fffc6c518d0
 request line:
   method: 'SETUP'
   uri:    'rtsp://10.3.0.48:7070//track1'
   version: '1.0'
 headers:
   key: 'Transport', value: 'RTP/AVP;multicast;client_port=5002-5003'
 body:
RTSP response message 0x7fffc6c51890
 status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
 headers:
   key: 'CSeq', value: '3'
   key: 'Date', value: 'Fri, Mar 23 2007 18:02:31 GMT'
   key: 'Transport', value:
'RTP/AVP;multicast;destination=226.255.0.48;port=5000;ttl=255'
   key: 'Session', value: '163'
 body: length 0

The major issue is that encoder B just fails if it gets the SETUP with the
wrong port combination; while encoder A accepts the setup but corrects the port
in the reply. udpsrc is then able to bind on the port since it opens on
multicast (shared=0).

BUT, we only got there due to this phase in the negociation:
0:00:00.369336740 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:784:gst_udpsrc_start:<udpsrc0> allocating socket for 0.0.0.0:5000
0:00:00.369624127 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:795:gst_udpsrc_start:<udpsrc0> got socket 10
0:00:00.369665497 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:797:gst_udpsrc_start:<udpsrc0> setting reuse 0
0:00:00.369704946 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:804:gst_udpsrc_start:<udpsrc0> binding on port 5000
0:00:00.369789664 19720      0x25be0c0 WARN                  udpsrc
gstudpsrc.c:945:gst_udpsrc_start:<udpsrc0> error: bind failed -1: Address
already in use (98)
0:00:00.370732089 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:784:gst_udpsrc_start:<udpsrc1> allocating socket for 0.0.0.0:5002
0:00:00.370974259 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:795:gst_udpsrc_start:<udpsrc1> got socket 10
0:00:00.371013078 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:797:gst_udpsrc_start:<udpsrc1> setting reuse 0
0:00:00.371052355 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:804:gst_udpsrc_start:<udpsrc1> binding on port 5002
0:00:00.371096882 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:853:gst_udpsrc_start:<udpsrc1> setting udp buffer of 524288 bytes
0:00:00.371137838 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:873:gst_udpsrc_start:<udpsrc1> have udp buffer of 262142 bytes
0:00:00.371295943 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:906:gst_udpsrc_start:<udpsrc1> bound, on port 5002
0:00:00.371423726 19720      0x25be0c0 LOG                   udpsrc
gstudpsrc.c:992:gst_udpsrc_unlock_stop:<udpsrc1> No longer flushing
0:00:00.372628098 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:784:gst_udpsrc_start:<udpsrc2> allocating socket for 0.0.0.0:5003
0:00:00.372879650 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:795:gst_udpsrc_start:<udpsrc2> got socket 13
0:00:00.372918492 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:797:gst_udpsrc_start:<udpsrc2> setting reuse 0
0:00:00.372957596 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:804:gst_udpsrc_start:<udpsrc2> binding on port 5003
0:00:00.373004080 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:873:gst_udpsrc_start:<udpsrc2> have udp buffer of 126976 bytes
0:00:00.373045067 19720      0x25be0c0 DEBUG                 udpsrc
gstudpsrc.c:906:gst_udpsrc_start:<udpsrc2> bound, on port 5003
0:00:00.373131960 19720      0x25be0c0 LOG                   udpsrc
gstudpsrc.c:992:gst_udpsrc_unlock_stop:<udpsrc2> No longer flushing

If this unicast setup could be skipped once we know it is multicast (cf. SDP);
this problem could be avoided.

It seems to be a poor reaction of the encoder based on something we should not
do...

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.