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

[Daniel Huhardeaux]

Craig Southeren a écrit :
> On Thu, 23 Nov 2006 12:40:51 +0100
> Daniel Huhardeaux <devel at 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