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

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

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.
 
If the requirements were interpreted strictly, the UAC
in a b2bua will follow the UAC rules as stated in 
Section 4.3.1. ie to essentially insert a H-I and add
and index of "1".
 
This may be insufficient. 
 
B2BUAs play an important role in Call control and a call/session
attempt across a B2BUA should be viewed as a single piece.
 
For example, if we had:
 
          1                   2
UAC (A)--------B2BUA or CC--------UAS (B)
|
|               3
 \---------------------------- Voice Mail
 
Lets say A calls B via a huntgroup. So, the 
It's the History-Info in the leg between
B2BUA and B (ie 2) that is likely to contain the
correct identity of B and therefore has to
be used when the call gets retargeted to Voice Mail.
Which means the History-Info header from leg 2 has
to make it back to leg 1.
 
For this to happen the History-Info header must
be copied over from leg 1 to leg 2 using the 
"Basic Forwarding" Rule in 4.3.3.1.3 ie:
 
Also: 
 
"In the case of a Request that is being
forwarded, the index is determined by adding another level of
indexing since the depth/length of the branch is increasing."
 
Reworking the index is important because the tree structure
has to be maintained.
 
I can think of two ways of dealing with this:
 
1. The Application is an acknowledged entity in the rfc.
Treat UAC/UAS not as an endpoint but as a component
that may be passed a list of History-Info headers by the Application.
 
The reworking of the index can either be Application reposibility
or UAC responsibility. 
 
We have two options:
 
1.1) UAC is probably where it should reworked
     as this fits with the proxy reqts of forwarding..and we are doing
     forwarding in a larger sense.
 
1.2) Let Application rework the index and pass it down to the UAC.
 
Also, the headers can be passed into the UAS from the Application to
address the voice-mail use-case identified above.
 
In either case, I suggest we add some language to clarify this. Because
currently the UAC is instructed to add a History-Info header with an
index value of "1". And the UAS is asked to simply copy back the H-I 
headers from the request to response. I find this insufficient.
 
2. Specify a model in which B2BUA plays a role and define
responsibilities.
 
What do you folks think?
 
Thanks,
Ganesh
 
_______________________________________________
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: Dean Willis <[email-masked]>
Date: Fri, 11 Aug 2006 13:18:49 -0500

> I am wondering if this leaves a gap and hinders achieving the

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