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

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 (
> >>
> >
> > 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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]