Re: [sipcore] SBC-friendliness of 4244bis

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.

-hadriel

On Sep 2, 2010, at 4:46 PM, Worley, Dale R (Dale) wrote:

> Somewhere Hadriel noted that he didn't want SBCs to be stuck with the job of tweaking History-Info values so that deficient UASs could interpret them correctly.  This is a very sound idea -- if H-I is defined well, SBCs shouldn't have to edit them at all.
> 
> However there is one exception for which I expect great market demand:  Having an egress SBC remove the hi-entry's that show the routing of the request *within* a service provider network, which more or less means every hi-entry since the request passed through the ingress SBC.
> 
> There is a similar requirement regarding H-I in responses.
> 
> I think we would avoid future trouble if we wrote a non-normative algorithm as to how an SBC could accomplish this.  On one hand, writing it would increase the chance that SBCs would implement this functionality correctly.  And on the other hand, writing it would ensure that we define H-I so that it carries the information that an SBC will need to do the job right.
> 
> (I am not putting this in the tracker as it is a very open-ended topic at present.)
> 
> Dale
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore