Subject: [Sip] Re: [Sip-implementors] Miss-ordered re-INVITE request

From: Markus Hofmann <[email-masked]>
Date: Tue, 23 May 2006 16:22:20 +0200

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-masked]]
> Sent: Tue 5/23/2006 5:56 AM
> To: Nataraju Basavaraju
> Cc: Leonid Fainshtein; [email-masked]
> 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-masked] on behalf of Markus Hofmann
>> Sent: Tue 5/23/2006 4:07 AM
>> To: Leonid Fainshtein
>> Cc: [email-masked]
>> 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-masked]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>> _______________________________________________
>> Sip-implementors mailing list
>> [email-masked]
>> 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 mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Nataraju Basavaraju" <[email-masked]>
Date: Tue, 23 May 2006 06:14:54 -0700

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-masked]]
Sent: Tue 5/23/2006 5:56 AM
To: Nataraju Basavaraju
Cc: Leonid Fainshtein; [email-masked]
Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request
 
Hi Nataraju,

Where in the RFC 3261?

Regards,
  Markus

Nataraju Basavaraju wrote:
> network problems that an new Re-INVITE-2 is faster as an ACK (RE-INVITE-1).
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 May 2006 12:00:59 -0400

> I think but I am not sure at the moment it is not allowed to send a

It definitely *is* legal to send a reINVITE without SDP. Its a key 
component of many B2BUA 3pcc call flows.

	Paul