[asterisk-dev] Regarding SIP performance

[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)

Regards,

Brian.