Hi Nataraju, this is not a offer/answer negotiation because it is a ReINVITE and not an initial INVITE.
I think but I am not sure at the moment it is not allowed to send a ReINVITE without SDP. Regards, Markus Nataraju Basavaraju wrote: > Hi Markus, > > If the re-INVITE-1 led to delayed negotiation scenario, I mean > re-INVITE-1 without SDP, then offer/answer negotiation would be > completed only when ACK for re-INVITE-1 is received. Till that time we > can't process any more INVITE requests for offer/answer negotiation... > hence re-INVITE-2 should be rejected by 491 response... > > Note: There could only one offer/answer negotiation happening aty any > point in time... > > Regards, > Nataraju A.B. > > -----Original Message----- > From: Markus Hofmann [mailto:[EMAIL PROTECTED] > Sent: Tue 5/23/2006 5:56 AM > To: Nataraju Basavaraju > Cc: Leonid Fainshtein; [email protected] > Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request > > Hi Nataraju, > >> [ABN] probably we may not be able to handle this way always. asuume the >> scenario, delayed negotiation scenarion with re-INVITE-1 and ACK is not >> been received, the offer/answer negotiation is still open, hence it >> should be rejected by 491 response. > > Where in the RFC 3261? > > Regards, > Markus > > Nataraju Basavaraju wrote: >> comments inline... >> >> Regards, >> Nataraju A.B. >> >> -----Original Message----- >> From: [EMAIL PROTECTED] on behalf of Markus Hofmann >> Sent: Tue 5/23/2006 4:07 AM >> To: Leonid Fainshtein >> Cc: [email protected] >> Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request >> >> Hi Leonid, >> >> in my opinion a 200 OK for the second Re-INVITE should be the right >> answer. The Re-INVITE-1/200 OK transaction is over the ACK transaction >> is started (which I do not see in you example). So it seems that UA-1 >> does not work rfc 3261 conform. But this scenario can happen through >> network problems that an new Re-INVITE-2 is faster as an ACK > (RE-INVITE-1). >> >> If you will never receive an ACK for the Re-INVITE-1 you UA-2 (tries to >> get an ACK be retransmit 200 OK (Re-INVIT-1) must send a BYE. I think >> the race condition does not affect the signalling and the the media path. >> >> [ABN] probably we may not be able to handle this way always. asuume the >> scenario, delayed negotiation scenarion with re-INVITE-1 and ACK is not >> been received, the offer/answer negotiation is still open, hence it >> should be rejected by 491 response. >> >> if it is a early media call, re-INVITE-2 could be accepted by 200OK... >> >> Regards, >> Markus >> >> >> Leonid Fainshtein wrote: >>> Hi, >>> >>> Is the following UAS behavior correct? >>> >>> UA-1 UA-2 >>> ------INVITE ---------> >>> <------200 ------------ >>> ------- ACK ----------> >>> ------ re-INVITE-1-----> >>> <------200 ------------ >>> >>> ------ re-INVITE-2-----> >>> <------ 400( with Retry-After header) ---- >>> >>> As you can see, the second re-INVITE arrives to the UAS when the >>> previous re-INVITE transaction is not confirmed yet (ACK is not >>> received). >>> What should UAS do in this situation? Silently ignore re-INVITE2? Reject >>> it with response 400 or 500? >>> Thanks, >>> Leonid >>> >>> _______________________________________________ >>> Sip-implementors mailing list >>> [email protected] >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> >> >> >> The information contained in this message may be confidential to Kodiak >> Networks, Inc. and its subsidiaries and protected from disclosure. If >> this message did not reach the intended recipient, or an employee or >> agent responsible for delivering it to the intended recipient, you are >> hereby informed that any distribution or copying of this communication >> is prohibited. If you have received this communication in error, please >> notify us immediately by replying to the sender of the message and then >> delete the message. Thank you > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
