UAC UAS
------------------------------------------------------------
INVITE-----------> -------------> INVITE
200 OK <---------- <------------- 200 OK
ACK (1) -----------> ( got lost )
Re-INVITE------->
<------------ 200 OK retransmitted
ACK (1) ----------->
-------------> re-INVITE
<------------ 491 ( ?? )
-------------> ACK (1 )
491 <------------
ACK (2)----------> ------------> ACK (2)
I think you are asking about the above call- sequence.
I think in this case after receiving the re-INVITE on the UAS ( before
it has received the ACK for previous INVITE-2XX ), the session using
offer-answer exchange has been established and using
rules/recommendation for processing re-INVITEs on an existing session. I
am not sure if a 491 Response should be sent/is appropriate.
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf
>>Of ext Ivar
>>Sent: Thursday, May 24, 2007 12:12 PM
>>To: indresh singh
>>Cc: [email protected]
>>Subject: Re: [Sip-implementors] UAC dialog 2xx retransmit wait time
>>
>>
>>Onle last question.
>>
>>You say UAC can send re-INVITE after 2xxx, so but for example
>>UAC sends
>>re-INVITE but UAS not got ACK, so you just get 491 from UAS ?
>>(Otherwise i dont see any point)
>>
>>I have got much wiser now, like yep, UAC must keep each invite 2xx
>>retransmit timer till it expires.
>>
>>Thanks,
>>
>>indresh singh wrote:
>>> Below are my thoughts
>>>
>>> Regards,
>>>
>>> Indresh K Singh
>>>
>>> On 5/23/07, Ivar <[EMAIL PROTECTED]> wrote:
>>>
>>>> Hi,
>>>>
>>>> After reading rfc multiple times i can't fugure out following:
>>>> If UAC dialog gets 2xx for INVITE, it waits 64 * T1 for 2xx
>>>> retransmissions and send ACK to it.
>>>> Does that mean UAC dialog may not send re-INVITE during that time ?
>>>>
>>>
>>>
>>> It can send a re-INVITE as the session is established at
>>this point of time
>>> and a re-INVITE/UPDATE can be used to modify the session.
>>64* t1 timer is
>>> being run to ensure that for any reason if there is a
>>retransmission of 2xx
>>> ( for example UAS send 2xx, but got no response, UAC sent
>>the ACK for first
>>> 2xx, but UAS has not received the ACK and it retransmitted
>>another 2xx. Now
>>> the first ACK sent by UAC may get lost in the network, so
>>for the second one
>>> the if the UAC does not respond with an ACK. UAS will not
>>be able to stop
>>> retransmission of his 2xx.
>>>
>>>
>>>
>>>> Or if it's allowed, what happens to timer ?
>>>>
>>>
>>>
>>> After the expiry of 64 * t1 timer expiry on the UAC,
>>retransmission related
>>> resources can be freed in the TU/UAC core and UAC will not
>>be responsible
>>> for sending ACK for any 2xx response recieved afterwards (
>>could be possible
>>> bcoz of network delays etc )
>>>
>>> And similar reverse version:
>>>
>>>> UAC dialog waits 2xx retransmissions,
>>>>
>>>
>>>
>>> UAC dialog waits for first 2xx response and sends an ACK.
>>After this if it
>>> receives a re-INVITE it should process it and not respond
>>with 491 and
>>> should separately handle the 2xx retransmission on the
>>previous INVITE-2xx
>>> transaction.
>>>
>>> Similarly on the UAS side if UAS has sent a 2xx response or
>>retransmitted
>>> 2xx response and has received an ACK for a 2xx response, then it can
>>> send/receive a re-INVITE on a separate transaction and if
>>it recieves an ACK
>>> on previous INVITE for next 64 * t1 second it should process it
>>> successfully.
>>>
>>> but UAS dialog send re-INVITE, is
>>>
>>>> it allowed(just kill wait timer) or "491 Request Pending"
>>must be sent.
>>>> _______________________________________________
>>>> 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
>>>
>>
>>_______________________________________________
>>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
