On Mon, May 11, 2009 at 3:48 PM, Peter Cai <newptcai at gmail.com> wrote: > Yeah, when you call pjmedia_transport_attach, rtp_src_addr will be reset to > zero. > > But. In most cases, this won't be a problem. I think that in certain step > of a call, rtp_src_addr will be set to correct value after attach media. > Just don't know where. > > > On Mon, May 11, 2009 at 9:42 PM, Michael Broughton < > Michael_Broughton at advanis.ca> wrote: > >> Peter Cai wrote: >> >>> Recently I found a potential bug in PJSIP. >>> >>> In the branch I marked "BUG", the code access the "udp->rtp_src_addr", >>> and this runs in the thread created by "pjmedia_endpt_create". >>> But the rtcp_src_addr might be reset to all "0" in main event process >>> thread. Which would then cause an assert fail. >>> (I can find the excat place where rtp_src_addr of a transport is >>> modified.) >>> >>> A trivial walk aroud is use PJMEDIA_UDP_NO_SRC_ADDR_CHECKING when create >>> this transport, which would skip the whole branch. >>> >> I am experiencing this issue as well. It seems to happen in a couple >> different places (on_rx_rtp, on_rx_rtcp). >> >> I guessed that the address fields are being zeroed out in another thread >> that calls transport_attach. However, I have not been able to confirm this. >> >> The rtp_src_addr is registered to pj_ioqueue_recvfrom(), so it will be filled up by the ioqueue when it calls on_rx_rtp() callback. So theoretically in the callback the value is always valid. Unless if this is that ugly race condition thing, where attach() is being called while a packet is being received... I recall you reported a similar case Michael (http://trac.pjsip.org/repos/ticket/460). cheers Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090512/8abb3f87/attachment.html>
