[Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Mon, 27 Nov 2006 11:02:14 +0100
Damien Sandras <dsandras at seconix.com> wrote:

..deleted

> > > 1: Establishing the media streams after having sent or received the ACK
> > > takes between 1 or 2 seconds during which the media stream is lost.
> > 
> > This seems to be only a problem on Linux. I'm not seeing this problem on
> > Windows.
> > 
> 
> I can see that problem on Windows too. Have you tried reproducing the
> problem? If so, how?

I've tried calling 411 at Free World Dialup, which I believe is an
Asterisk server. If not, or if you know of another accessible Asterisk
server I can use for testing, please let me know.

I've also made SIP calls between two Windows simpleopal devices with no
problems.

> > What is OPAL during the 1 or 2 seconds? Is this how long it takes to
> > open the sound device on Linux? I'll need more information before I can
> > work out how to fix the problem
> 
> No, it is the time it takes to start the threads, open the device, start
> the codecs, and so  on.
> 
> You have a debug 4 output, so you can clearly see what happens.

The delay occurs across these three log messages:

2006/11/27 10:24:10.115	  0:13.867	SIP Handle...er:843fa00	OpalCon	Selected media stream PCM-16 -> G.711-ALaw-64k

2006/11/27 10:24:11.192	  0:14.944	 Housekeeper	SIP	Set state Terminated_Success for transaction 2 INVITE

2006/11/27 10:24:11.198	  0:14.950	SIP Handle...er:843fa00	OpalMan	OnOpenMediaStream Call[1]-EP<pc>[Default],OpalAudioMediaStream-Source-PCM-16

There are no log messages during this one second, so OPAL must be doing
something that does not contain logging.

Looking at the code, the function that is executed during this time is
the virtual function OpalConnection::CreateMediaStream, which is the
code that opens the RTP device or the audio device.

For a normal audio call, this will be either OpalPCSSConnection::CreateMediaStream
or SIPConnection::CreateMediaStream. If you have time, you might try
adding some logging to these functions to see what is consuming the time.

If it turns out that opening the sound device is consuming the time, we
may need to find a way to "pre-open" the audio device prior to making a
call.

> > > 2: If OPAL sends an INVITE with 3 codecs in a given order, and that
> > > Asterisk supports the 3 same codecs but with a different priority order,
> > > it will send the 200 OK with those 3 codecs in the order it prefers.
> > > OPAL will then choose the codec it prefers and send the media with that
> > > codec. It could happen that Asterisk uses another codec from the list,
> > > ie a codec for which OPAL is not ready to receive a stream.
> > > 
> > > e.g. :
> > > INVITE PCMU, iLBC, PCMA
> > > 200 OK iLBC, PCMA, PCMU
> > > 
> > > OPAL will send the stream using iLBC.
> > > Asterisk could decide to send the stream using PCMU.
> > > However OPAL expects iLBC...
> > 
> > Replying to an INVITE with more than one codec has a very specific
> > meaning, and OPAL does not support these semantics. Fortunately, very
> > few devices seem to do this.
> 
> Many devices are doing this, including Asterisk which is very popular,
> believe me. Some popular french ITSP's like  Wengo are also working that
> way, so it is really not so uncommon...

I will look further at the appropriate RFCs and see what SIP expects to
happen.

Thanks for the information

   Craig

-----------------------------------------------------------------------
 Craig Southeren          Post Increment – VoIP Consulting and Software
 craigs at postincrement.com.au                   www.postincrement.com.au

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243656905      MSN: craig_southeren at hotmail.com
 Mobile: +61 417231046      Jabber: craigs at jabber.org

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting