Markus Hofmann wrote:
> 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.
It definitely *is* legal to send a reINVITE without SDP. Its a key
component of many B2BUA 3pcc call flows.
Paul
> 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 mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
