Subject: [sipcore] SBC-friendliness of 4244bis

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 16:46:44 -0400

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 2 Sep 2010 17:09:51 -0400

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:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 17:36:46 -0400

________________________________________
From: Hadriel Kaplan [[email-masked]]

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.)

Given that we have someone present who is well aware of the tastes of that market, we might as well get input to minimize future trouble.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 3 Sep 2010 03:56:52 -0400

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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 7 Sep 2010 13:56:45 -0400

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.
________________________________________

That would be unfortunate -- the handling of H-I in responses is as important as handling of H-I in requests, and in principle, the H-I in an outgoing response can be edited to show precisely what the service provider wishes to show about the call's handling.  In any case, the service provider shouldn't edit the H-I entries concerning routing in any other service provider's network (unless there is some sort of joint operating agreement).

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 7 Sep 2010 23:43:02 +0200

It is worth pointing out that for the ISDN information to the caller that the call has been forwarded is not subject to privacy, only the identity where the call has been forwarded to. So in this case, it would be reasonable to expect that part of the H-I entry survices the SBC.

There are sound service reasons for doing this, i.e. the users complain when they end up talking to a different party to the one they expected - with a normal tendency to hang up immediately (possibly with an intervening "Oh wrong number sorry".

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Worley, Dale R (Dale)
> Sent: Tuesday, September 07, 2010 6:57 PM
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [sipcore] SBC-friendliness of 4244bis
> 
> 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.
> That would be unfortunate -- the handling of H-I in responses 
> is as important as handling of H-I in requests, and in 
> principle, the H-I in an outgoing response can be edited to 
> show precisely what the service provider wishes to show about 
> the call's handling.  In any case, the service provider 
> shouldn't edit the H-I entries concerning routing in any 
> other service provider's network (unless there is some sort 
> of joint operating agreement).
> 
> Dale