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.
That should be the case here.
/O
_______________________________________________
--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
