Subject: RE: [Sipping] b2bua/call control aspect for rfc4244 (History-Info header)

From: "Ganesh Jayadevan \(gjayadev\)" <[email-masked]>
Date: Fri, 11 Aug 2006 14:31:26 -0400

Hi Dean,

I see what you are saying about B2BUAs in general.

I also proposed another alternative of an Application
being able to pass a HI tuple to a UAC (or UAS) that can forward
(or backward) propogate. This interface and function can be
defined in the limited context of this rfc.

Without this call control b2buas will implement rfc4244 in 
an undefined way leading to inconsistent infomration models
and the purpose of the rfc will be defeated.

thanks,
Ganesh

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, August 11, 2006 2:19 PM
To: Ganesh Jayadevan (gjayadev)
Cc: [email-masked]; Cullen Jennings (fluffy); Sudipto Mukherjee
(sudiptom); [email-masked]; [email-masked];
[email-masked]; Mohammad Al-Taraireh (maltarai)
Subject: Re: [Sipping] b2bua/call control aspect for rfc4244
(History-Info header)

On Aug 11, 2006, at 6:11 AM, Ganesh Jayadevan ((gjayadev)) wrote:

> Folks,
>
> rfc4244 (History-Info) addresses what the UAC, UAS, and the proxy must

> do with the History-Info header.
> True to the tradition of SIP, a b2bua is not given any special status 
> but is seen as a concat of a UAS-UAC.
>
> I am wondering if this leaves a gap and hinders achieving the 
> objectives of the rfc.
>

The problem is that defining what a B2BUA does, in general, seems to be
an intractable problem.

You have one specific sub-model of B2BUA that is fairly proxy-like in
its behavior in mind.

However, another model of B2BUA serves as an anonymizer. It's entire
role in life is to keep one side from knowing anything about the "real
UA" on the other side of the B2BUA. This probably includes disclosing
that there's even a B2BUA in the loop -- the "other side"  
should see the anonymizing B2BUA as the terminal node.

So by this logic, we should specify that B2BUAs do not propagate
History-Info at all.

Now, clearly that's also wrong for the general case. There may not even
be a "general case" for B2BUA behavior.

So we end up with a situation where each application of a B2BUA requires
an analysis of the appropriate transparency behavior for that specific
application.

Given that there are arguably a large number (if not infinite set) of
B2BUA applications, this means that a thorough description of the
behavior of B2BUAs with respect to any specific extension is
sufficiently difficult as to be infeasible.

Contrast this with the bounded problem space of describing the
extensions behavior wrt to UAC, UAS, proxy (possibly stateless,
transaction stateful, and dialog stateful) and registrar.

Now it may be that there are a finite set of design patterns for B2BUAs
that can be cleanly defined, each of which has an obvious set of
transparency requirements. I'm certainly not convinced that this set is
small or the problem tractable, but if you'd like to try and establish
an appropriate taxonomy along with discussion of the transparency
behavior of each pattern, I'll be happy to read your results.

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Aug 2006 14:57:30 -0400

> defined in the limited context of this rfc.

Yes, I can see how it would make sense to permit the application to do this.

I agree with dean on the general intractability of specifying anything 
useful in general for a B2BUA.

	Paul