Summary:	ASTERISK-09734: SIP Reinvite Packets incorrect Sequence causes no audio when more than 1 softswitch in callpath.
Reporter:	Rudy K. (cyberglobe)	Labels:
Date Opened:	2007-06-22 07:03:05	Date Closed:	2011-06-07 14:01:02
Priority:	Blocker	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) Functional_Thinktel_Reinvite.txt ( 1) sip_reinvite_bug.txt ( 2) SIP_Reinvite_issue.ods ( 3) thinktel_reinvite.txt
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. ****** ADDITIONAL INFORMATION ****** You may view the initial issue here. http://bugs.digium.com/view.php?id=9986 I felt I had to open a new ticket cause the scenario was slightly different and is causing a blocking effect.
Comments:	By: Rudy K. (cyberglobe) 2007-06-22 07:08:39 Actually what I meant about the SIP information passing is when there are 3 or more servers in total between the 2 UACs. By: Alex Coseru (alexcos) 2007-08-17 12:17:26 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 By: Joshua C. Colp (jcolp) 2007-11-28 09:52:09.000-0600 Okay, I'll tackle this issue! cyberglobe: We are no longer dealing with 1.2 issues so I'm going to continue with alexcos. alexcos: Can you provide the console only output without sip debug and sip.conf? It looks as though direct RTP setup stuff was used which would cause the issue you mentioned. If it is not enabled in your sip.conf then the code that prevents it did not work and needs to be fixed. By: Joshua C. Colp (jcolp) 2008-02-14 13:41:32.000-0600 Suspended due to lack of response with vitally needed information by alexcos.