[asterisk-dev] Regarding SIP performance

[Johansson Olle E]

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