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 10:54 AM > Cc: sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] Re-transmitting of ACK for RE-INVITEaftera > newre-invite > > > >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. > [ABN] if the retransmission on re-INVITE is lost, then it must reported as 408 and call should be terminated. I don't remember the particular section, but it is mentioned that if any of the mid dialog INVITE requests lead to 408/481, then the call would be terminated(assuming session timer is not running for this call)... Yes, if you want to send re-INVITE(2) you need to wait for 64*T1, after the first 2xx received for re-INVITE(1) > 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 _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
