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