| Summary: | ASTERISK-09687: RTP Reinvite fails when more than 1 softswitch in place. | ||
| Reporter: | Rudy K. (cyberglobe) | Labels: | |
| Date Opened: | 2007-06-15 01:19:19 | Date Closed: | 2011-06-07 14:03:01 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/RTP |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) Functional_Thinktel_Reinvite.txt ( 1) issue9986.diff ( 2) SIP_Reinvite_issue.ods ( 3) SIP_Reinvite_routes.txt ( 4) thinktel_reinvite.txt | |
| Description: | Using Asterisk 1.2.18 I am trying to determine why we are experiencing a call problem with Asterisk and our SIP provider ThinkTel. We are connected in the following manner: <UA>--<Asterisk>--<TT-OpenSER>--<TT-Metaswitch>--<VoIP2PSTNGateway> We have canreinvite=yes and nat=no on all ends. The issue that we are having a problem with is that asterisk has MISSING data execution to properly transfer the RTP Streams to the proper destinations. Because of this, it is keeping the Gateway data coming into the Asterisk Box. Here is the breakdown of the callpath Code: UA Asterisk OpenSER MetaSwitch VoIP2PSTNGateway > 102 Invite >> <<<<< Trying < > Invite 102 >>> <<<<<<<< 183 Session Progress < <<<<<< 183 SP < <<<<<<<<<<< 200 OK 102 INVITE < > ACK >>>>>>>>>> << 200 OK 102 < > 103 Invite >>> > 102 ACK >>>>> << 102 Invite < ;reinvite rtp stream to Gateway >> RTP STREAM to VOIP 2 PSTN >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<< 200 OK 103 INVITE < > 103 ACK >>>>>> **** Missing Step here between Asterisk and OpenSER/Metaswitch*** > 200 OK 102 >> <<<<< 102 ACK < Does anyone know what just happened? Answer: Asterisk just left 102 Call Sequence from Asterisk to OpenSER/Metaswitch up in limbo. How you ask? Well where the Missing step is, it should have shut down the 102 INVITE sequence between Asterisk to OpenSER to MetaSwitch to Gateway. Not sure who is currently at fault (Asterisk or OpenSER/MetaSwitch) but would it not be logical to keep the INVITE 102 running on both ends instead of increasing the value to 103? Attached below is my SIP and RTP Stream data for you guys to analyze. I hope this helps to bring about a fix to this scenario. I hope someone can offer a patch for this issue too. ****** ADDITIONAL INFORMATION ****** The issue that needs to be resolved is why Asterisk is creating an invite 103 when there is a 102 session in play. Asterisk has the 102 session still active while trying to force a 103 into play. This is incorrect and is the source of the problem why Asterisk has failed to reinvite due to the actual Gateway still being connected to the Asterisk box via the 102 Invite. Is there a patch for this currently? | ||
| Comments: | By: Joshua C. Colp (jcolp) 2007-06-15 07:26:48 Please attach a sip debug to accompany this. By: Rudy K. (cyberglobe) 2007-06-17 06:42:04 Uploaded... Thought I have already uploaded but guess I forgot to hit the upload button last time. By: Rudy K. (cyberglobe) 2007-06-18 06:51:53 After further reading of the RFC 3261, lotacted at http://www.rfc-editor.org/rfc/rfc3261.txt Asterisk has failed to properly reinvite the session for the remote UAC because it has initiated a new INVITE request instead of re-invite-ing the actual 102 request as per section 14 of the RFC. In my understanding of the RFC, the UAC and the UAS (*) 200 ACK for 102 INVITE should have concluded before the INVITE 103 (which should have been 102) to the TT-OpenSER to modify the data stream for a RTP Re-Invite for the Audio Stream. By: Joshua C. Colp (jcolp) 2007-06-18 08:25:36 Please try the attached patch for the sequence number related stuff. By: Rudy K. (cyberglobe) 2007-06-19 00:49:55 Patch did not work. Returned 500 Bad Request from remote server. Going to go to level 3 tech support at Thinktel to help determine further as to why this is failing. Will keep you posted. By: Rudy K. (cyberglobe) 2007-06-19 01:14:29 Ok working from originals and actually I have established only 1 true reinvited call. Luckily I have captured the SIP logs for the session and now am going to compile the call pathways for the failed vs successful call. Will have it in OOo Spreadsheet format. Once compiled I will upload the spreadsheet after. From my preliminary checking of the logs, it looked like there was a packet loss exactly when it was transmitting the INVITE 103 and therefore * had to reissue the request which actually made the session work. By: Rudy K. (cyberglobe) 2007-06-19 01:54:09 Ok Openoffice Open Spreadsheet format uploaded along with my functional thinktel SIP/RTP Reinvite Debug output. My conclusions were right, When the 103 INVITE sequence was delayed by a few commands, the session actually worked. Therefore, I think that we should delay all audio stream reinvites to the remote UAS/UAC until the initial UAC establishes the Reinvite first. Or to reduce the delay time, atleast try it between the OK and ACK of the 102 reinvite. Waiting for the patch to test now. No Solution yet? :( By: Rudy K. (cyberglobe) 2007-06-20 15:05:21 As per the SIP Reinvite issue.ods spreadsheet, Is there anyway to create a patch to resequence the 103 INVITE to be delayed after the 102 INVITE Re-Invite sequence command's OK or ACK request? By: Rudy K. (cyberglobe) 2007-06-22 07:12:36 Please close this as this has been opened under http://bugs.digium.com/view.php?id=10037 since scenario has changed and the severity is different. The DIFF patch does not fix the problem since it causes a missequencing. By: Joshua C. Colp (jcolp) 2007-06-22 11:07:23 Closed per request. | ||