>Probably the bug here would be that, 2nd RE-INVITE (cseq 2) been tried >to send out before the 64*t1 time duration lapsed after first 2xx for >re-INVITE (cseq 1).
Do you mean the 2nd re-invite should not be send out until the 64*t1 lapsed? What if the re-transmission of the 1st re-invite is lost? Otherwise I cannot hold a call once a call is establish. Please comment. Richard WU ASTRI B, Nataraju wrote: >Comments inline... > >Thanks, >Nataraju A B > > > >>-----Original Message----- >>From: [EMAIL PROTECTED] >> >> >[mailto:sip-implementors- > > >>[EMAIL PROTECTED] On Behalf Of Richard Wu >>Sent: Tuesday, October 17, 2006 9:00 AM >>To: sip-implementors@cs.columbia.edu >>Subject: [Sip-implementors] Re-transmitting of ACK for RE-INVITE after >> >> >a > > >>newre-invite >> >> >>Hi all, >> RFC 3261 Section 14.1 said... "The rules for transmitting a >> >> >re-INVITE > > >>and for generating an ACK for a 2xx response to re-INVITE are the same >>as for the intital INVITE". Consider the following re-invite scenerio >> >> A B >> ---- RE-INVTE (cseq 1) ---> >> ---- RE-INVTE (cseq 1) ---> /* re-transmission */ >> >> <------ 200OK (cseq 1) ------ >> ----- ACK (invite 1) ---> >> >> ---- RE-INVTE (cseq 2) ---> >> <------ 200OK (cseq 1) ------ /* response to the first >>re-transmission re-invite */ >> <------ 200OK (cseq 2) ------ >> ----- ACK (invite 1) ---> /* should the ua reply the ACK for >> >> >the > > >>re-transmission 200 OK within 64*T1? */ >> ----- ACK (invite 2) ---> >> >>My question is "should the ua reply the ACK for the re-transmission >>200 OK within 64*T1"? Thanks in advance. >> >> >> >[ABN] 3261 is very clear about this statement... > ><<3261 , sec 13.2.2.4 2xx Responses > The UAC core considers the INVITE transaction completed 64*T1 seconds > after the reception of the first 2xx response. At this point all the > early dialogs that have not transitioned to established dialogs are > terminated. Once the INVITE transaction is considered completed by > the UAC core, no more new 2xx responses are expected to arrive. >/3261>> > >Probably the bug here would be that, 2nd RE-INVITE (cseq 2) been tried >to send out before the 64*t1 time duration lapsed after first 2xx for >re-INVITE (cseq 1). > > > >>Richard Wu >>ASTRI >> >> >>This message (including any attachments) is for the named >> >> >addressee(s)'s > > >>use only. It may contain >>sensitive, confidential, private proprietary or legally privileged >>information intended for a >>specific individual and purpose, and is protected by law. If you are >> >> >not > > >>the intended recipient, >>please immediately delete it and all copies of it from your system, >>destroy any hard copies of it >>and notify the sender. Any use, disclosure, copying, or distribution >> >> >of > > >>this message and/or any >>attachments is strictly prohibited. >> >> >>_______________________________________________ >>Sip-implementors mailing list >>Sip-implementors@cs.columbia.edu >>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > > > This message (including any attachments) is for the named addressee(s)'s use only. It may contain sensitive, confidential, private proprietary or legally privileged information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any attachments is strictly prohibited. _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
