[asterisk-bugs] [Asterisk 0011400]: Resetting the SEQ number back to 0 without sending a new INVITE SSRC

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11400 
====================================================================== 
Reported By:                kanderson
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   11400
Category:                   . I did not set the category correctly.
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:            1.4.13  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             11-28-2007 11:33 CST
Last Modified:              11-28-2007 12:54 CST
====================================================================== 
Summary:                    Resetting the SEQ number back to 0 without sending a
new INVITE SSRC
Description: 
When a caller is placed on hold asterisk is resetting the SEQ number back
to 0 without sending a new INVITE SSRC.  This is causing occasional one way
audio with  my carrier and delays after retrieving callers from hold.  I
have captures done on the PBX, my carrier (Bandwidth.com), and Level 3.  I
am available for any additional information, patch tests, or special
requests.  Thank you.
====================================================================== 

---------------------------------------------------------------------- 
 kanderson - 11-28-07 12:54  
---------------------------------------------------------------------- 
File- This only when retrieving calls from hold.  

Just for the record my symptoms:
When calls are placed on hold and retrieved occasionally the PSTN side can
not hear the IP or there is a 5 second delay.  Half of the time it is fine.


Bellow are the statements that we (Centrix, Bandwidth.com, and Level 3)
have made.

1)  Audio packets are transmitted and received from Centrix equipment.
2) The issue can only be recreated if Bandwidth.com is utilized in the
call path (ie. other carriers utilized by Centrix do not have the same
issue). 
3) The issue has effected all clients of Centrix, including those with no
changes or interventions to their setup.
4) With or without the firewall active the problem still occurs.
5) The internal clock for the phone is within sync with the servers.
6) Disabling the network time protocol daemon (to eliminate any possible
time shifts during a call) does not effect the issue.
7) A different pbx on a different subnet has the same issue.
8) A different phone on different Internet connection (ie DSL) has the
same issue.
9) Limiting the codec to g711 or g729 has no effect.
10) The calling number or called number has no effect, issue occurs
regardless. 
11) Power cycling the phone or pbx has no effect.
12) There is no apparent break in the RTP stream.
13) Unassociated network traffic does not appear to be a factor.
14) There does not appear to be an correlation between CPU,
memory,read/write cycles, or bandwidth utilization on the pbx.
15) Re-registration cycle during issue has no effect.
16) The no audio condition only occurs after a call is retrieved from
hold.
17)  Some calls suffer from a five second delay which adheres to all the
above findings (only with Bandwidth.com, occurs on different pbx or phone,
number called/calling has no effect, ect).
18)  Assigning the phone a public IP thereby eliminating NAT does not
correct the issue.
19) A phone on the same subnet as the pbx does not correct the issue.
20)  The issue appeared 'suddenly' after months of service with no
correlations to changes made by Centrix Networks.
21)  The percentage of calls with issues fluctuates and has no known
correlation to server functions or load.
22)  Replacing or resetting modem cards where they hand off to the SS7
network has no effect.

Thank you for your help 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-28-07 12:54  kanderson      Note Added: 0074499                          
======================================================================