[asterisk-bugs] [Asterisk 0010037]: SIP Reinvite Packets incorrect Sequence causes no audio when more than 1 softswitch in callpath.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10037 
====================================================================== 
Reported By:                cyberglobe
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10037
Category:                   Core/RTP
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     new
Asterisk Version:            1.2.18  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        No 
Request Review:              
====================================================================== 
Date Submitted:             06-22-2007 07:03 CDT
Last Modified:              08-17-2007 12:17 CDT
====================================================================== 
Summary:                    SIP Reinvite Packets incorrect Sequence causes no
audio when more than 1 softswitch in callpath.
Description: 

Working with Thinktel to debug why our audio stream gets stuck with our
UAC connecting to their UAC but their UAC still stuck with Asterisk, we had
stumbled upon a solution by coincidence.

When our network was overloaded, our SIP packets had to retransmit the 103
REINVITE request after the Initial 102 REINVITE request was completed. 
This caused us to establish a two way audio link without any problem.  When
the 103 INVITE request never failed and did not retransmit, it always
becomes a blocker.

Basically, the issue is with the sequence how the 103 REINVITE for RTP
Bridging request gets sent to Thinktel.  The packet gets sent too early and
causes no audio either way.  (My UAC is transmitting to their UAC but since
their UAC is stuck talking to My Asterisk, ignores my UAC's Audio Stream) 
When the offending packet is retransmitted, it establishes 2 way audio
without any problems.

I have managed to create 3 different instances where it caused the
retransmission of the 103 reinvite request and all 3 times were able to
successfully establish two-way audio between the UACs.

Therefore the diagram for this configuration problem is as follows:
<MY UAC>-<MY-Asterisk>-<TT-OpenSER>-<TT-MetaSwitch>-<TT-UAC>
When SIP reinvite fails, the call stream is stuck as follows:
<MY-UAC>>>>>>|<TT-UAC>--<MY-Asterisk>
My UAC transmits to TT-UAC but TT-UAC ignores/blocks the request cause its
channel is opened for sending and receiving to MY Asterisk Box.
When we cause a retransmit request to ensure that the packets were being
retransmitted, the RTP Bridge worked and established as follows:
<My-UAC>--<TT-UAC>

I have requested Thinktel to address this issue via a patch on their
OpenSER box until Digium is able to patch this up by checking for the
following conditions:
- INVITE sip: request
- User-Agent: contains Asterisk
- X-asterisk-info contains (RTP bridge)
When it sees this first initial packet, it would drop this packet
altogether.  This would force Asterisk to retransmit this packet and due to
the retransmit, would cause the RTP Bridging to function.

However, this is just a patch to a problem that needs to be addressed by
Digium.  This could also potentially fix the existing problems that has
plagued the reinviting requests with Asterisk PBX with other vendors.  

BONUS FEATURE if fixed: When we were retransmitting the reinvite request,
the bonus was that the RTP Stream Reinvite was SEEMLESS.  We did not hear
ANY 100-200ms interruption in audio during the audio transfer what we
currently experience when an RTP Bridging occurs when there is only 1 or 2
Servers inbetween 2 UACs.

This issue occurs when there are 3 or more Servers that the SIP
Information must pass through.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0009986 RTP Reinvite fails when more than 1 sof...
====================================================================== 

---------------------------------------------------------------------- 
 alexcos - 08-17-07 12:17  
---------------------------------------------------------------------- 
Confirmed in 1.4.8


Huawei IpPhone -> asterisk1 -> asterisk2 -> patton

10.36.2.85 -> 10.36.2.1 -> 10.105.177.21 -> 10.105.177.14



The RTP setup is a mess , the huawei phone is trying to send the rtp to
10.105.177.14 , and the patton expects it from 10.36.2.1
Asterisk2 seems to be the problem , but not using an reinvite..

Asterisk1 and Asterisk2 are the same , version: Asterisk 1.4.8


If you need more info , pls contact me.

I have attached a debug file.

Regards 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-17-07 12:17  alexcos        Note Added: 0069001                          
======================================================================