Hi,
Comment at the end.
Vijay Gurbani wrote:
>
> Christian Jansson wrote:
> [...]
> > > > 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 am talking about the case where a 200 OK arrived at a UAC and the UAC
>ACK'ed it. The question now is how long should it maintain the INVITE
>transaction to allow subsequent 200 OKs to arrive and be matched against
>the INVITE to create additional call legs.
>
>An INVITE will be "unbounded in time" if a 1xx ends up creating an "early"
>call leg. If no further final responses arrive on that call leg (due to the
>downstream proxies successfully CANCEL'ing those branches), then the UAC
>can destroy these "early" call legs after a suitable delay.
I had a look at the draft, and I didn't find anywhere written what the
time should be.
However, I do remember that issue was discussed on the list a while ago,
so you may want to check the archieves. If I remember correctly it was
discussed that this is pretty much an implementation issue. For example,
some people always ACK every final response to an INVITE (and then also
sends BYE if it was a 200 final response), even if the client never sent
an INVITE in the first place.
I do think this should be mentioned in the draft, though.
Regards,
Christer Holmberg
Ericsson Finland
>
> - vijay
> --
> Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
> Internet Software and eServices Group
> Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
> Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184
> _______________________________________________
> 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
