Re: [sipcore] SBC-friendliness of 4244bis

[Hadriel Kaplan <[e-mail]>]

On Sep 2, 2010, at 5:36 PM, Worley, Dale R (Dale) wrote:

> ________________________________________
> From: Hadriel Kaplan [[e-mail]]
> 
> Interesting idea.  There's no doubt SBCs will strip/anonymize the heck out of this thing (some already do for current Hist-Info).  But I'm not sure there's a one-size-fits-all model.  For example I see different rules being employed between carriers, vs. between a carrier and subscribers, vs. between enterprises and carriers.  But you do have a point.  Especially if we want GRUU's to survive.
> _______________________________________________
> 
> What I am particularly concerned about is that we define H-I so that SBCs aren't *forced* to do scorched-earth stripping of H-Is if the  policy requirement is to remove certain subsets of the information.  E.g., if an egress SBC wants to fold all the activities within the carrier to appear to be just one proxy step, it needs to be able to identify the point in the H-I tree that is the matching ingress SBC.  
> 
> (BTW, it seems to me that this sort of folding is a nice form of "topology hiding", in that everything *outside* of the carrier remains unchanged, but the carrier admits nothing about how it accomplishes its operations.  With some care, the carrier can still reveal diversion steps that it has performed that are part of the service model that is to be revealed to the user.)

As far as I can tell, it's not just their own local entries they'd want to remove - they'd want to remove *all* the "extraneous" ones; i.e. all the ones not necessary to make voip applications work.  If it was just "folding", then SBCs can already do that, by inserting a specific entry or param on the appropriate H-I position on ingress, and the egress SBC removing all entries after that position.  But that will break apps, because you usually need to pass on the real divert entries.  
 
Currently I see deployments of legacy H-I having the SBC stripping specific entry positions known to be generated due to normal routing req-uri replacement, changing the host portion of the H-I URIs to not reveal IP's/hostnames, and normalizing phone number usernames.  And I see them being removed from responses all-together, especially in call centers where they don't want the caller to know the specific agent it was sent to. 

-hadriel