Dale, We don't have a HERFP solution and we don't have 130. At present we only have (or we shortly will have) 199. However, I am doubtful about the usefulness of 199 in this context.
First, let's consider the busy case (CCBS). The UAS will return 486. It will not have established an early dialog, and therefore it will not send 199. Second, let's consider the no reply case (CCNR). The caller will often make the decision to use CCNR after a number of ring cycles, without necessarily waiting for 487 or 199. Therefore 199 will be useful only in a minority of cases. We can specify its use as an optional enhancement, but we should not rely on it for mainstream feature operation. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: 20 August 2008 21:37 > To: [email protected] > Subject: Re: [BLISS] thoughts on > draft-ietf-bliss-call-completion - HERFP > > > From: Jonathan Rosenberg <[EMAIL PROTECTED]> > > On the HERFP problem, I think the issue is really deeper than that. > [...] I also think its a mistake to require 199 or 130 or any > other 'HERFP' response - again, making this too > complicated. Simplicity is key for this feature IMHO. > > The intention of the design is to utilize information available from > HERFP but not require it. (We cannot require it, as we do not require > that the caller have memory.) But in the face of forking, we do have > the problem that the caller may have reached several different UASs > that each implement CC -- in a perfect world, the agent would know > what all the monitors are and would subscribe directly to each of > them. > > We do prescribe that the CC SUBSCRIBE be sent to the original To URI, > in hopes that it forks identically to the original INVITE, and we > recommend that the SUBSCRIBE be sent to the URI in the CC Call-Info > header, but if the agent can see and remember HERFP responses with CC > Call-Info headers, it provided a more reliable path to the UAS that > generated it. > > Dale > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
