On 25 Jan 2011, at 16:39, Jeff Pyle wrote: >> Then there is some misunderstanding somewhere. Before the first 183 >> arrives, mediaproxy cannot lock onto anything as it doesn't yet have >> information about both endpoints. It needs a request (INVITE) and a reply >> that carries media (183/200), before it can even begin to listen to >> packets. So how can it lock to media before even allocating the ports and >> listening is beyond me. > > Interesting. I will re-verify the leaky media has stopped before the 183 > arrives. A plausible explanation is that I am incorrect, and it is still > flowing after the 183.
You may be right. A closer look at the code shows that the relay may learn stream addresses even before receiving any SDP from the destination. I have forgotten this detail, so you can have a problem even if the leaky media stops before the SDP in first 18x >> I checked the code and it does reset on any new request/reply. > > Does this mean that it resets once on any request/reply pair, or that it > resets on each new request and each new reply? On each request and each reply. Once a new SIP message (be that request or reply) with SDP is received it will reset. > One fine point: We have been saying 183 throughout this entire > discussion. That isn't accurate. In most cases the GSX at this carrier > sends a 180 with SDP. I bring it up only to rule out some weird > difference that may exist within Mediaproxy between a 183 and a 180 with > SDP. An SDP is an SDP, regardless of the code it rides in on, no? Yes. As long as it has SDP is processed, regardless of code. -- Dan _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users