Bufferprobe udpsrc - port dows not match any defined one

[Federico Zamperini]

Sorry: on windows netstat -na.

Il 20/02/2013 09:24, Federico Zamperini ha scritto:
> 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