On 25 Jan 2011, at 15:35, Jeff Pyle wrote: >>> Or, perhaps something already available in the code to force a reset of >>> some sorts when the 18x w/ SDP message comes back? By this point, the >>> leaky media has stopped and the legit media is flowing. >> >> I don't think this is your case, because the relay already handles this. >> it will reset it's knowledge of the learnt addresses with every >> request/reply in dialog. So when the 2nd 183 comes in, it does reset the >> ports and attempts to relearn them. If things would be as you describe >> them (1st media stream has stopped when the 2nd 183 comes), then it >> should simply work because the relay would reset and learn the ports from >> the 2nd media stream. But I suspect that the 1st media stream still flows >> a bit past the 2nd 183 and the relay locks onto that again instead of >> locking on the 2nd media stream (that probably comes only after it >> re-locked to the 1st). Otherwise I cannot explain why it wouldn't work >> for you as the relay relearns the addresses after every 183/200 > > Here's the thing: there is only one 183, not two. > > The carrier sends only a 100, then some of this "leaky" media as I am > calling it. I think the term "leaky" fits because it arrives outside of > any SDP. The relay locks onto this media. By the time the carrier does > send the 183 (and SDP), the leaky media has stopped and the legit media > has started. But, since there is only one 183, it appears the relay > doesn't have an opportunity to reset. There is only one stream at a time.
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. > > We have examined the Mediaproxy accounting records after the fact. They > show the port on the carrier-side as the one from the leaky media, not the > one from the SDP. For some reason the relay does not reset at 200 OK time. I checked the code and it does reset on any new request/reply. > > This is on Mediaproxy 2.3.8, as far as we can go on CentOS with the Python Hmm, I really can't recall if that version had this ability or not. I suggest you try the latest version and see if it fixes your problem. > package limitations. I am rebuilding into Debian Lenny with Opensips 1.6 > and Mediaproxy 2.4 from the package repositories. Perhaps we will see a > different behavior with more current versions. -- Dan _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
