Hi Anthony, Thanks for your time, I will open the case with the traces. It is reproducible and occurs once or twice per week, but to reproduce in the LAB you would need to have sipp with the scenario, it won't be reproducible if the client is not dropping the 200Ok. I'm managing now to drop the RE-INVITES if the initial ACK is not received. This will give time for the first transaction to complete or simply timeout. I'll be testing during this week. Best regards, Flavio E. Goncalves CTO - SipPulse Routing and Billing Solutions for SIP Phone: +55 48-3025-8590, +1 248-688-0960 VoIP: SIP:flavio@opensips.org,Skype:flaviogoncalves1 Linkedin: www.linkedin.com/in/flavioegoncalves Twitter: www.twitter.com/asteriskguide 2013/5/24 Anthony Minessale <anthony.minessale@gmail.com>
A manual description of sip traffic with no trace or anything else is only going to get an educated guess. Beating the box so badly that its dropping udp packets is not going to go over well no matter how you slice it. If you have a reproducible problem, open a Jira with some traces and a more detailed description and preferably a simple reproducible test case.
On Fri, May 24, 2013 at 2:27 PM, Flavio Goncalves <flavio@sippulse.com>wrote:
Hi Anthony,
It is not a retransmission, the CSEQ is much higher and the branch is different. It is actually another transaction. The CSEQ of the first INVITE is 103, the second INVITE is something bigger than 400000. The biggest issue here for us is not receiving the BYE. We had built a mechanism in the proxy to send a BYE if not receiving the ACK in 5 seconds, but the ACK for the REINVITE disables it. We will change the mechanism to accept only the ACK for the first transaction, but anyway, I believe FS should have sent the BYE. If this can be fixed (if actually is broken), it would help to eliminate many billing issues when late negotiation is involved and the client stops answering (caused by network failures or client overload).
Best regards,
Flavio E. Goncalves CTO - SipPulse Routing and Billing Solutions for SIP Phone: +55 48-3025-8590, +1 248-688-0960 VoIP: SIP:flavio@opensips.org,Skype:flaviogoncalves1 Linkedin: www.linkedin.com/in/flavioegoncalves Twitter: www.twitter.com/asteriskguide
2013/5/24 Anthony Minessale <anthony.minessale@gmail.com>
Its probably not a re-invite but a retransmission of the same one because it never got the response.
That RFC is trying to say you can't send another invite while you are waiting for a reply to the current one but you can send other things like info. The problem is when one side sends invite and the other end replies but the sender does not get that reply, they will keep sending the invite until it gives up.
On Thu, May 23, 2013 at 3:38 PM, Flavio Goncalves <flavio@voffice.com.br
wrote:
Hello,
I'm having a really strange issue on billing related to late negotiation. The call end up hanged with no BYE.
There is a dialer sending thousands of calls through and OpenSIPS to a termination based on FreeSwitch. I have a SIP call flow as below. Some times during the day, when the volume is high, the UAC drops some 200Ok and FS send a reinvite in the middle of the Initial transaction.
----INVITE --------------- Proxy --INVITE ---------------> FS <----200 OK -------------- Proxy <---200 OK- ------------- FS <--REINVITE--------------- Proxy <-REINVITE--------------- FS ---481 leg does not exit-> Proxy ---481------------------> FS <-- ACK (REINVITE)-------- Proxy <-ACK(REINVITE)---------- FS ----CANCEL ---------------> Proxy ---CANCEL --------------> FS <---200 Ok ---------------- Proxy <----200 Ok ------------- FS
FS is sending a reinvite before ACK comes from the client.
I have two questions:
1) Is it valid to send a reinvite in the middle of an existing transaction?
According to the RFC3261 Section 14.
Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction.
1. If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE.
2. If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE.
But it is confusing because just below it says the opposite.
However, a UA MAY initiate a regular transaction while an INVITE transaction is in progress. A UA MAY also initiate an INVITE transaction while a regular transaction is in progress.
2. Shouldn't FS send a BYE after sending a 200Ok and not receiving the ACK?
If a UAS generates a 2xx response and never receives an ACK, it SHOULD generate a BYE to terminate the dialog.
Best regards,
Flavio E. Goncalves
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org