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
