> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Johansson Olle E > Sent: 16 October 2006 14:34 > > 16 okt 2006 kl. 15.11 skrev Brian Candler: > > > 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) > > > > Or, set up the call as normal - one call leg to Asterisk, transcode > and another > call leg and media stream to the other device.
I don't think you can do that as is - the original poster said that the INVITE has gone to the called phone with the codec list from the server but the IP address and port of the calling phone: "but with SDP pointing at the first phone". This seems to be a bit dodgy - it's not necessarily legitimate SDP from either the caller or Asterisk. What you might have to do, if the called phone answers the INVITE with a codec that the calling phone does not support, is CANCEL the original INVITE and then make a new INVITE using the IP address of the server, and then transcode as appropriate. _______________________________________________ --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
