[asterisk-dev] Regarding SIP performance

[Steve Langstaff]

 > From: asterisk-dev-bounces at lists.digium.com 
> [mailto:asterisk-dev-bounces at lists.digium.com] 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.