Bufferprobe udpsrc - port dows not match any defined one

[Federico Zamperini]

I suggest to do a couple of things:
- low number ports might be reserved; try to use high values (from 
wikipedia: The registered ports are those from 1024 through 49151)
- use wireshark to see packets' dest and src address/port
- use netstat -npa (on the receiver side -- on windows, too) to list 
listening sockets
Federico

Il 19/02/2013 19:14, Wes Miller ha scritto:
> I compiled a C++ gst_parse_launch() version of the examples for 1.0 rtpbin
> modifying them to run on 0.10 (needs to run in windows and linux).  Works
> great.
>
> Now, what I really want to do is wait for a message to arrive at the
> (receiver) udpsrc, pick the sender's IP and port out of the data I get from
> a buffer probe on udpsrc then build a sender pipeline to talk back to
> whomever.
>
> So I added the buffer probe to the (receiver) udpsrc src pad.  Also works
> great.  My callback gets called as expected.
>
> Then I ran into a snag.  I seem to be getting messages from my expected
> sender (10.253.5.239 - just sending audio continuously) and from 127.0.0.1.
> After adding some debug printf's I see .5.239's data arriving and also see
> when 127.0.0.1's data arrives.  I also get their port numbers and that's
> where the question comes from.
>
> The ports returned (for either address) by gst_netaddress_get_ip4_address()
> and by gst_netaddress_to_string() match each other but do not match either
> of the ports I specified in my original pipeline (502, 5003, 5004 similar to
> the original example) nor do the ports from the two addresses match.
>
> So, simply, why?  Are the ports specified to udpsrc and udpsink get
> translated to some other form?  Are they really "request ports" that assign
> working ports for the stream to use (like tcp does)?
>
> Thanks,
>
> Wes