On Mon, Oct 16, 2006 at 01:28:13PM +0200, Johansson Olle E wrote: > >I've tested it now, and in my SVN build, which is about 10 days out > >of date, > >it appears to be broken. > > > >Full description posted at http://bugs.digium.com/view.php?id=8152 > > > >In summary: the two endpoints think they can both use different > >codecs at > >the same time, with the RTP stream running directly between them :-( > > If they're not compatible, we should not re-invite or set up the RTP > directly. > I'll check the bug report.
OK. I don't know the best way to solve this though, because the second leg INVITE has already offered a bunch of codecs to the second phone, some of which the first phone doesn't support, but with SDP pointing at the first phone. We don't learn which one the second phone chooses until it's too late. Some possible ideas: * Probe the second phone with OPTIONS first, to discover what codecs it supports. Adds latency to every call. or * Make the INVITE to the second phone only offer codecs which the first phone offered. Then if the call is rejected due to no compatible codec (606?), try again using the normal two-leg setup, with SDP pointing at the Asterisk server. This to me seems the cleanest way. or * Allow the wrongly-setup call to proceed anyway, and then when you realise there's an incompatibility immediately fix it with some re-INVITEs (yuk) Regards, Brian. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
