Hi, Comment at the end. Christian Jansson wrote: > > see comment in the end. > > Vijay Gurbani wrote: > > Harpreet Ahluwalia wrote: > > > > > > Hi, > > > > > > Refering to bis03: > > > > > > The definition of a transaction is > > > "... all messages from the first request > > > sent from the client to the server up to a final (non-1xx) > > > response sent from the server to the client. A transaction > > > is identified by the CSeq sequence number (Section 10.20) > > > within a single call leg ..." > > > > > > Consider the scenario that I am a UAC, I send an INVITE to my outbound > > > proxy. The proxy forks it to n other servers. > > > Now, I could end up getting n 18Xs ( or even n 200 ) responses. All > > > these will have the same Cseq no. So, do all these 18Xs & 200s form a > > > part of the same transaction? Going by definition the transaction > > > should end the moment it gets the first 200. Which means the other 200s > > > belong to a NULL ( already deleted) transaction! > > > > Not quite. UAs, besides being aware of a transaction, are also aware of > > call-legs. A call leg is not established until a 200 OK is received (this > > is somewhat debatable since 100rel may force an "early" call leg). So, > even > > if you get multiple 1xx (each with a different tag in the To), they update > > the same INVITE transaction. When you get the first 200 OK, a call leg is > > established. Successive 200 OK establish further call legs based on the > > original INVITE transaction. > > > > > Also, I as the UAC don't know how many people the proxy had forked the > > > request to. So, for how long should I maintain the state of the > > > transaction, I could get n 180s for that transaction. I don't know > > > whether the 200s belong to the same transaction or not. > > > > I don't know off hand if the bis specifies a caching period for a UAC > where > > they have to maintain the INVITE transaction after sending an ACK to the > > first 200 OK it receives. If it does not, 32s seems an appropriate time > to > > maintain the transaction. By that time, all straggler 200 OKs should have > > arrived. > >I don�t think it is that easy. Isn�t is so that if the UAC receives a 1xx >response it should wait for an unlimited amount of time for the final response. >Probably the user will hang up if it takes too long time, but still an INVITE >transaction can be unbounded in time. I think (correct me if I'm wrong) that the question was about for how long the UAC should keep the transaction alive AFTER it has received and ACKed the first final response, in case it will receive more final responses for the same transaction. Regards, Christer Holmberg Ericsson Finland > > Christian Jansson > Hotsip > www.hotsip.com > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] title:System Designer fn:Christer Holmberg end:vcard
