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

[Craig Southeren]

On Sun, 26 Nov 2006 12:14:29 +0100
Julien Puydt <jpuydt at free.fr> wrote:

..deleted

> Here is how gstreamer does, as far as I know : they get the data and 
> feed it to their codecs, which return something which measures their 
> confidente it is "correct data" for them.
> 
> So by elimination, they get the right codec, which can then be confirmed 
> and better tuned afterwards.

This sounds like it could require a lot of resources. 

Imagine a mobile device that has only limited CPU and supports a wide
variety of audio and video codecs. Pushing every received RTP packet
through every offered codec in order to find one that seems to works
would require a lot of extra code to be written, and would require a lot
of extra CPU. And it still doesn't address the other issues I described.

I think there some other issue at work here.

Can someone provide me with a trace log of a call that has the "three
second delay"? I'm thinking that perhaps the remote end is sending a 183
with media session information, but for some reason OPAL is not
processing the media until the 200 OK is received.

But until I get a level 4 trace, I won't know for sure...

   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