[asterisk-bugs] [Asterisk 0012708]: Dead air between answer and packet2packet bridge

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12708 
====================================================================== 
Reported By:                kactus
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12708
Category:                   Core/RTP
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.0-beta8 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-22-2008 20:26 CDT
Last Modified:              07-21-2008 09:51 CDT
====================================================================== 
Summary:                    Dead air between answer and packet2packet bridge
Description: 
Hi we have been testing asterisk 1.6 extensively as we intend to replace
our long in the tooth 1.2 box that acts as our gateway between our offices
and the switched telephony network.

Asterisk 1.6 talks to directly to a cisco call gateway via sip which talks
to the out side world via PRI

One issue that we have noticed repeatedly is that there is a large delay
between when a call is answered and when voice traffic actually flows. The
delay is also asymmetrical and of the scope of about 2 seconds. This is
very noticeable as calling someone generally misses the entire greeting.

Call flow essentially goes like this:
start call -> ringing -> answered (other party start talking “welcome to
company this is Cameron”) -> their voice flows 2 seconds later and we
hear “ameron”

If we talk they can't here anything either at the beginning.

I have been mainly testing this with a snom 190 (have also tried sp962)
connected via sip to the 1.6 box (over nat).

We have also tested this by passing the voice out to one of the larger
voice providers (who also use cisco equipment) and they have stated time
and time again that it is not their end. Both Cisco gateways run
unauthenticated accepting calls from particular ips automatically.

RTP debug information is attached (RTP stats attached to bottom of it.)

Please let me know if you need anything else. We have run this on two 1.6
boxes one running beta 8 the other running beta 9.

====================================================================== 

---------------------------------------------------------------------- 
 kactus - 07-21-08 09:51  
---------------------------------------------------------------------- 
Hello Ranahimal

For this one box I have kept things as simple as I can so my dial plan
is:

[from-sip55]
exten => h,1,Hangup()
exten => _.,1,Dial(IAX2/Account:Pass at GW/${EXTEN})

I have now set up a couple of different tests and have had a longer play
with the systems and am perplexed as for the first time I am experiencing
variable performance including occasionally better than PSTN.

ATB = Trixbox 2.6
SVN1 = SVN-trunk-r132312 on xen sitting on same network as ATB
A1.2 = current core at datacentre with quadspan e1 card
SVN2 = SVN-trunk-r132312 on freebsd at datacentre talking to sip provider
(67ms)

snom -> ATB -> A1.2 is pstn speed ("elcome")
snom -> ATB -> SVN2 looses the first second or so (ie the starting
"welcome")
snom -> SVN1 -> A1.2 is variable from pstn speed to dropping a second of
voice (this is one or the other not a range ie its occasionally quick but
usually drops the full "welcome").
snom -> SVN2 is very quick, faster than pstn the W is quite clearly made
out in "Welcome" but first second is slightly garbled
snom -> SVN1 ->SVN2 is faster than pstn but first second is much more
garbled. (this might be due to the sip provider though)

It seems svn playing with svn is very quick, but mixing older boxes and
newer boxes causes more delays. I'm not sure if this is due to different
sip handling code but I can confirm that there is significant improvement
over the previous 1.6 beta9 which experienced at worst over 2 seconds of
dead air consitently. 

I know the logical thing to test would be the A1.2 to the sip provider to
confirm that its responsible for the garbling but unfortunately I'd need to
change the ip of the A1.2 for it to authenticate and the box is too busy to
take off line even now at night.

I'll contact the provider to add a couple of IP's to the range and update
once they have allowed it.

Regardless it is much better than beta 9. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-21-08 09:51  kactus         Note Added: 0090520                          
======================================================================