Hi Benny, On 28 Jan 2010, at 16:41, Benny Prijono wrote: > On Wed, Jan 27, 2010 at 2:29 PM, Ruud Klaver <r.klaver at sping.nl> wrote: >> >> Logs included, zipped because of size. As you can see I upgraded to 1.5.5, the result seems to be the same. You can see that two stream objects are created, I only received once call during this log. I do actually see UDP traffic between the two correct IPs, but wireshark is not identifying it as RTP. Perhaps it's the traffic that is sent when silence is detected on the conference bridge? I can't quite recall what that looked like. >> > > As far as I can see, the log looks alright. Call is established, ICE > connectivity check is successful, so there shouldn't be any problem > with connection. This is reinforced by the fact that the endpoint > received keep-alive indication from the other endpoint (maybe that's > what you see in Wireshark, the STUN Binding Indication keep-alive > packet). > > So my guess is the audio is muted or not connected to the stream in > the conference bridge? Bear in mind that the UPDATE request will cause > stream to be destroyed and recreated, which means that you'd loose > your (call) media interconnection in the conference bridge and you'd > need to reconnect it again in on_media_update() callback. > > Cheers > Benny Indeed you were right, there was a second stream created in response to the UPDATE request. We omitted connecting it to the soundcard on the conference bridge. Thanks for the help! Best regards, Ruud Klaver Sping
