Re: [Insipid] Will the identifier pass unchanged through B2BUAs?

Uhhh... just to be clear, I was making an individual comment in that email, not a corporate position statement or any some such.

My point was that since the use-cases people are planning to do for INSIPID's Session-ID have now gone far beyond troubleshooting, the odds are we can't rely on it always being passed through end-to-end from originating Enterprises through various service providers to the far-end, without being modified in-transit.  I can't *prove* it won't be, but that's just my hunch, since we've seen this movie play out before.

The good news is we don't need the Session-ID to be used in STIR for caller-id verification, so there's nothing to worry about.
:)

-hadriel

On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> wrote:

> Hi,
> 
> I just got a publication request for the requirements document:
> 
> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08
> 
> The following is one of the requirements in the draft, which was one of
> the main reasons for creating this WG:
> 
>>   REQ3: The solution must require that the identifier, if present, pass
>>   unchanged through SIP B2BUAs or other intermediaries.
> 
> Hadriel, who works for an important SBC vendor and is one of the authors
> of the requirements document, sent the comments below to the STIR list a
> couple of weeks ago (see email below).
> 
> How should I interpret those comments in the context of my AD review of
> this document and, even more importantly, as the responsible AD for this
> WG (as you know, we have had many scope-related discussions in the past)?
> 
> Thanks,
> 
> Gonzalo
> 
> 
> -------- Original Message --------
> Subject: 	Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter)
> Date: 	Tue, 16 Jul 2013 10:21:13 -0400
> From: 	Hadriel Kaplan <hadriel.kaplan@oracle.com>
> To: 	Richard Shockey <richard@shockey.us>
> CC: 	IETF STIR Mail List <stir@ietf.org>
> 
> 
> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" <richard@shockey.us> wrote:
> 
>> I actually believe INSIPID is equally important to the overall task
> since it
>> is the track and trace elements of this that can ultimately enable some
>> enforcement. I wish there was some more discussion on how the mechanisms
>> would work at the edge SIP/SS7 network gateways since that clearly has
> been
>> the center of most of the reported problems.  I still think something
> needs
>> to be done to police that traffic but that is still ultimately a
> regulatory
>> effort.
> 
> I agree we need a tracking/tracing mechanism, but in my opinion we
> cannot and should not rely on INSIPID Session-ID at all for that.  They
> have gone beyond benign troubleshooting-type purposes now, which means
> there is absolutely no guarantee the Session-ID will make it intact
> across service providers in all cases.  In fact, my hunch is it won't.
> 
> Regardless, the Session-ID isn't what we really need for tracing a bad
> caller-id call.  Even without Session-ID, the service provider's CDRs or
> logs can be used to trace it back to the peering connection and peer
> upstream provider the call came in from.  What we also need is a list of
> SPIDs the call request has crossed through, so we can trace it back
> further upstream.  Kinda like a Via header, but with very different
> properties and purpose.  We've talked about doing that before, back when
> there was talk about creating a registry of SPIDs.  What ever happened
> to having a registry of SPIDs?
> 
> -hadriel
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid