>> Evan Borgstrom <evan.borgstrom(a)ca.mci.com> 11/16/05 5:27:52 PM >>>

Evan, I would not invest the time to look into the SER side of your problem. Because this is a general problem. Instead of SER any other network element (router, switch, etc.) could change the order of the packets. BTW I guess this problem occurs on your SER because the ACK and the INVITE are handled by different SER processes. And as SER is not call-statefull there is no parameter to solve this situation. I fear you are right that this problem is not covered by any RFC, but the solutions seems logical to me: if this a generic problem, then either the UAC is not allowed to send a re-INVITE until the first INVITE is completed, or the UAS has to accept a re-INVITE after sending the 200 OK. But how does the the UAC know that the ACK reached the UAS so that it can send the re-INVITE now? It cant know that, so it would have to wait for a timer before it could send the re-INVITE. On the other side the INVITE transaction is completed for the UAS by sending the 200 OK (the ACK is a new transaction, according to the branch). Thus I think the UAS (the Cisco gateway) should accept the re-INVITE without complaining. Just for curiosity: is the call established or does the Cisco gateway drop the call after sending the 500? Regards Nils On Wednesday 16 November 2005 07:51, Greger V. Teigre wrote: > Evan, > I'm not able to match your text with the messages you show. The message > timestamped 16:51:51.559657, does it go to Cisco? It is shown to go to > Asterisk and it doesn't make sense. > However, until the Cisco gw receives the ACK from Asterisk, no call has > been established and the reINVITE cannot be matched. IMO, this is not a > Cisco bug. It seems very strange indeed that ser should send a reINVITE > before the ACK in the same call. Even without FIFO, an INVITE is likely to > take more time to process than a loose routed ACK. I would try to log more > thoroughly in SER to see what happens in processing the ACK and the > reINVITE. It could be a problem in your ser.cfg, but it seems strange > indeed. > g-) > > ----- Original Message ----- > From: "Evan Borgstrom" <evan.borgstrom(a)ca.mci.com> > To: <serusers(a)lists.iptel.org>rg>; <serdev(a)lists.iptel.org> > Sent: Wednesday, November 16, 2005 12:05 AM > Subject: [Serdev] ACK before INVITE on re-INVITE causes Cisco AS's to > return a 500 error > >> Hey all, >> >> This has more to do with Asterisk & Cisco AS's IMO but I thought it >> would be interesting to get some responses from this group before I >> begin the battle with Cisco to get a bug report underway. >> >> We have an Asterisk box acting as a PBX sending calls to our SER >> instances. The asterisk box has "reinvite=yes" in the sip.conf file >> which causes Asterisk to send a re-INVITE for the call once it receives >> the 200 OK. This re-INVITE has it's SDP changed to that of the IP Phone >> behind the Asterisk box so that all media doesn't need to traverse it. >> This works fine except in certain instances where messages get out of >> order and it causes our Cisco GW's to error the call with a generic 500 >> message. When the messages are in the correct order the 500 error does >> not appear. >> >> So here's the situation, user behind the asterisk box picks up the >> phone and dials a PSTN destination. Asterisk fires off the initial >> invite and everything proceeds as normal and we eventually receive the >> 200 OK message to which the Asterisk box replies with ACK and a new >> INVITE that come in this order (X = Asterisk, Y = SER, Z = Cisco): >> >> U 2005/11/15 16:51:51.557322 X.X.X.X:5060 -> Y.Y.Y.Y:5060 >> ACK >> >> # >> U 2005/11/15 16:51:51.557948 X.X.X.X:5060 -> Y.Y.Y.Y:5060 >> INVITE >> >> SER accordingly processes the two messages and replies 100 Trying to >> the new INVITE message. Here's where the problem occurs, SER then sends >> these messages out to the PSTN gateway but the order has been reversed: >> >> # >> U 2005/11/15 16:51:51.558937 Y.Y.Y.Y:5060 -> X.X.X.X:5060 >> SIP/2.0 100 trying >> >> # >> U 2005/11/15 16:51:51.559000 Y.Y.Y.Y:5060 -> Z.Z.Z.Z:5060 >> INVITE >> >> # >> U 2005/11/15 16:51:51.559657 Y.Y.Y.Y:5060 -> X.X.X.X:5060 >> ACK >> >> When this happens the Cisco GW replies with a 500 error message and the >> following is sent to the Cisco's logs: >> >> # >> U 2005/11/15 16:51:51.711355 Z.Z.Z.Z:5060 -> Y.Y.Y.Y:5060 >> SIP/2.0 500 Server Internal Error. >> >> >> Nov 15 21:51:51.613: HandleUdpSocketReads :Msg enqueued for SPI with >> IPaddr: Y.Y.Y.Y:5060 >> Nov 15 21:51:51.613: *****CCB found in UAS Request table. ccb=0x653BCD0C >> Nov 15 21:51:51.613: CCSIP-SPI-CONTROL: act_sentsucc_new_message >> Nov 15 21:51:51.617: CCSIP-SPI-CONTROL: act_sentsucc_new_message_request >> Nov 15 21:51:51.617: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE >> Nov 15 21:51:51.617: sip_stats_status_code >> Nov 15 21:51:51.617: sipSPICheckRequest: CheckRequest fail on method 102 >> error code: 2 and status: 500 >> >> >> Is there any parameter that I can set to ensure that message leave SER >> in the order they enter? Should the Cisco be able to handle this >> condition (I check a number of different sections of the RFC but >> couldn't find anything specific for either side)? >> >> Thanks, >> Evan >> >> _______________________________________________ >> Serdev mailing list >> serdev(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serdev > _______________________________________________ > Serdev mailing list > serdev(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serdev