Re: [Ekiga-list] ekiga answers with delay ¿...?

[Daniel Huhardeaux <devel tootai net>]

Craig Southeren a écrit :
> On Thu, 23 Nov 2006 12:40:51 +0100
> Daniel Huhardeaux <devel tootai net> wrote:
>
>   
> > Julien Puydt a écrit :
> >     
> > > [...]
> > >       
> > > > to reach". So, ekiga wastes 1 or 2 seconds for establishing the connexion
> > > > ¿...?. With twinkle there isn't this delay.
> > > >     
> > > >         
> > > Known bug : asterisk begins to send the voice before it acknowledged 
> > > which codec it will use for that!
> > >   
> > >       
> > Not a bug in Asterisk: Ekiga is not ready but should be.
> >     
>
> I've only just noticed this thread, so please accept my apologies for
> the late reply.
>
> It's not unusual for a calling endpoint to receive media before it
> receive acknwledgement that the call has been answered. With some
> protocols (like H.323) this can be due to the timing of the signalling
> (which is carried via TCP) and the RTP (which is carried on UDP). For
> SIP, it can be due to the media and signalling taking different paths.
> Or it can just be due to delays in the receiving endpoint.
>
> Regardless, the calling endpoint should be ready to receive RTP at any
> time after it sends to call offer and OPAL should do this already.
>
> However, if the receiving endpoint uses a different payload type than
> the one offered, then the receiving endpoint won't be able to accept the
> incoming RTP data until the signalling reply is received. 
>
> I know that Asterisk has a nasty habit of changing the payload type -
> perhaps this is what is happening? Can anyone confirm?
>   
Hi Craig,

hereunder an exchange we had end of october about this behaviour -final 
answer from Damien-, after having open a bug on asterisk mantis.

Le dimanche 29 octobre 2006 à 17:52 +0100, Daniel Huhardeaux a écrit :

> > Damien Sandras a écrit :
> > 
>   
> > > > > > >>>>         
> > > > >           
> > > > > >>> [...]
> > > > > >>>
> > > > > >>>
> > > > > >>> I have done a debug log using ethereal, and I notice the following
> > > > > >>> behavior :
> > > > > >>>
> > > > > >>> 1) Ekiga sends the INVITE
> > > > > >>> 2) Ekiga receives the 200 OK
> > > > > >>> 3) Immediately after, Asterisk starts sending the media streams
> > > > > >>> 4) Ekiga opens the audio channels and sends the ACK
> > > > > >>>
> > > > > >>> The RFC tells that the media streams should not be sent before the ACK
> > > > > >>> is received. Asterisk doesn't follow this. So I conclude the bug is in
> > > > > >>> Asterisk not in Ekiga... 
> > > > > >>>
> > > > > >>> I'll see if I can find an easy to implement workaround.
> > > > > >>>   
> > > > > >>>       
> > > >         
> > > > >> Would it not be better to open a bug on mantis (bugs.digium.com)?
> > > > >>     
> > >       
> > > >
> > > > Somebody can do it, yes.
> > > >   
> >     
> > #8244
> > 
> > Damien, hereunder the response from Ole  ;-) 
> > 
>   

Ah well yes, he is right, I was sure I had read something else
elsewhere.

I will see if it is easy to change OPAL for that (I have doubts).


> > ----------------------------------------------------------------------
> >   oej - 10-29-06 10:35
> > ----------------------------------------------------------------------
> > Well, you should be ready to receive media as soon as you send the INVITE.
> > Let's try to find the various RFCs and throw them at each other... I am
> > sure
> > 
> > In reality, as soon as you make an offer, you need to be able to receive
> > audio on the ports you specify.
> > 
> > I don't see this as a bug. Check the implementations in various other
> > phones.
> > ---------------
> > So here's my throw of RFC 3264, Section 5.1:
> > 
> > "Once the offerer has sent the offer, it MUST be prepared to receive media
> > for any recvonly streams described
> > by that offer. It MUST be prepared to send and receive media for any
> > sendrecv streams in the offer, and send
> > media for any sendonly streams in the offer (of course, it cannot actually
> > send until the peer provides an
> > answer with the needed address and port information). In the case of RTP,
> > even though it may receive media
> > before the answer arrives, it will not be able to send RTCP receiver
> > reports until the answer arrives."
> > --------------------
> > Say hello to Damien from me, I hope that he can join us at AstriVideoCon
> > in Paris!
> > 
> > Good luck fixing this bug in Ekiga   :-) 
> > 
> > ----------------------------------------------------------------------
> >   oej - 10-29-06 10:37
> > ----------------------------------------------------------------------
> > Not a bug in Asterisk, bug in Ekiga until proven otherwise   :-) 
> > 
> > 
>   
-- Daniel