[asterisk-dev] Regarding SIP performance

[Steve Langstaff]

> From: Brian Candler
> Sent: 16 October 2006 14:11
>
> 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.

Bear in mind that you might be issuing regular OPTIONs messages to the
phone anyway, for 'qualify' operation - could these be modified to be
"OPTIONS with SDP" to get an idea of the codec capabilites of the phone?