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.
- 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
