Subject: Re: [dispatch] New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt

From: Cullen Jennings <[email-masked]>
Date: Mon, 9 Mar 2015 08:58:51 -0600

The heart of this draft gives me, ah , heartburn. The issue is 

   For a provider to receive reimbursement for providing relay service
   on a call the FCC requires that the provider supply call detail
   including the IP address of the device the TRS user is using for the
   call. 

First of all what IP. The IP of their phone behind their linksys nat? the public IP of the TURN server? the VPN? None of these are a viable way to authenticate that the user should receive this services and the IETF should implicitly endorse that they are. Furthermore the IETF should be just as concerned about privacy for people using a VRS as people that do not need one and this sort of reveal my IP address even if I want location privacy is not great. 

Given the lack of any security around this and the TRS-5 requirement, I wonder if one can just look at the via list and use that?

If we do proceed with this, I don't think the call-info is the appropriate place to put it. I think a new header would be the right thing.

Can you provide a pointer to the actually FCC rules for this?

If the goal is purely to check the user is in the US, then having the VRS check that they were sending media to an IP address inside the US seems like it would be a better solution. 

Thanks

> On Jan 13, 2015, at 9:14 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Dispatchers:
> 
> I have just submitted a new draft (see below) that needs to be dispatched. It defines a new Call-Info 'purpose' parameter value.
> 
> The intended audience for this draft is quite limited - to the providers of the Video Relay Service in the US, and to the FCC that sponsors that service. The Intro section explains this.
> 
> I'm hoping this can be dispatched without causing a lot of bother for anybody. I don't anticipate that it needs time in Dallas. IIUC documents of this sort are often AD sponsored.
> 
> 	Thanks,
> 	Paul
> 
> -------- Original Message --------
> Subject: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt
> Date: Tue, 13 Jan 2015 07:46:47 -0800
> From: [email-masked]
> To: Paul Kyzivat <[email-masked]>,        "Paul Kyzivat" <[email-masked]>
> 
> 
> A new version of I-D, draft-kyzivat-dispatch-trs-call-info-purpose-00.txt
> has been successfully submitted by Paul Kyzivat and posted to the
> IETF repository.
> 
> Name:		draft-kyzivat-dispatch-trs-call-info-purpose
> Revision:	00
> Title:		Telecommunications Relay Service Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)
> Document date:	2015-01-13
> Group:		Individual Submission
> Pages:		4
> URL: http://www.ietf.org/internet-drafts/draft-kyzivat-dispatch-trs-call-info-purpose-00.txt
> Status: https://datatracker.ietf.org/doc/draft-kyzivat-dispatch-trs-call-info-purpose/
> Htmlized: http://tools.ietf.org/html/draft-kyzivat-dispatch-trs-call-info-purpose-00
> 
> 
> Abstract:
>   This document defines and registers a value of "original-identity"
>   for the "purpose" header field parameter of the Call-Info header
>   field in the Session Initiation Protocol (SIP).
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Scot Brooksby <[email-masked]>
Date: Mon, 9 Mar 2015 22:24:33 +0000

Cullen,

The FCC rules for Relay providers can be found at:

http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=1&SID=76afe7404ca0539183b8ee9b6d78e8be&ty=HTML&h=L&r=PART&n=pt47.3.64#se47.3.64_1604

Specifically, you want to look at §64.604, paragraph (b)(2)(vi) (quoted below - with my emphasis on the paragraph).

(2) Call data required from all TRS providers. In addition to the data requested by paragraph (c)(5)(iii)(C)(1) of this section, TRS providers seeking compensation from the TRS Fund shall submit the following specific data associated with each TRS call for which compensation is sought:
    (i) The call record ID sequence;
    (ii) CA ID number;
    (iii) Session start and end times noted at a minimum to the nearest second;
    (iv) Conversation start and end times noted at a minimum to the nearest second;
    (v) Incoming telephone number and IP address (if call originates with an IP-based device) at the time of the call;
    (vi) Outbound telephone number (if call terminates to a telephone) and IP address (if call terminates to an IP-based device) at the time of call;
**(vii) Total conversation minutes; **
    (viii) Total session minutes;
    (ix) The call center (by assigned center ID number) that handled the call; and
    (x) The URL address through which the call is handled.
    (3) Additional call data required from Internet-based Relay Providers. In addition to the data required by paragraph (c)(5)(iii)(C)(2) of this section, Internet-based Relay Providers seeking compensation from the Fund shall submit speed of answer compliance data.
    (4) Providers submitting call record and speed of answer data in compliance with paragraphs (c)(5)(iii)(C)(2) and (c)(5)(iii)(C)(3) of this section shall:
    (i) Employ an automated record keeping system to capture such data required pursuant to paragraph (c)(5)(iii)(C)(2) of this section for each TRS call for which minutes are submitted to the fund administrator for compensation; and
    (ii) Submit such data electronically, in a standardized format. For purposes of this subparagraph, an automated record keeping system is a system that captures data in a computerized and electronic format that does not allow human intervention during the call session for either conversation or session time.

Thanks,
Scot

Scot Brooksby
Engineering Director, Architecture and Infrastructure
Sorenson Communications

> -------- Forwarded Message --------
> Subject: Re: [dispatch] New Version Notification for draft-kyzivat-dispatch-trs-
> call-info-purpose-00.txt
> Date: Mon, 9 Mar 2015 08:58:51 -0600
> From: Cullen Jennings <[email-masked]>
> To: Paul Kyzivat <[email-masked]>
> CC: [email-masked] <[email-masked]>
> 
> 
> First of all what IP. The IP of their phone behind their linksys nat?
> the public IP of the TURN server? the VPN? None of these are a viable
> way to authenticate that the user should receive this services and the
> IETF should implicitly endorse that they are. Furthermore the IETF
> should be just as concerned about privacy for people using a VRS as
> people that do not need one and this sort of reveal my IP address even
> if I want location privacy is not great.
> 
> Given the lack of any security around this and the TRS-5 requirement, I
> wonder if one can just look at the via list and use that?
> 
> If we do proceed with this, I don't think the call-info is the
> appropriate place to put it. I think a new header would be the right thing.
> 
> If the goal is purely to check the user is in the US, then having the
> VRS check that they were sending media to an IP address inside the US
> seems like it would be a better solution.
> 
> Thanks
> 
> 
> 
> > I have just submitted a new draft (see below) that needs to be dispatched. It
> defines a new Call-Info 'purpose' parameter value.
> >
> > The intended audience for this draft is quite limited - to the providers of the
> Video Relay Service in the US, and to the FCC that sponsors that service. The
> Intro section explains this.
> >
> > I'm hoping this can be dispatched without causing a lot of bother for anybody.
> I don't anticipate that it needs time in Dallas. IIUC documents of this sort are
> often AD sponsored.
> >
> > 	Thanks,
> > 	Paul
> >
> > Title:		Telecommunications Relay Service Purpose for the Call-Info
> Header Field in the Session Initiation Protocol (SIP)
> --
> You received this message because you are subscribed to the Google Groups
> "VRS Interop" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email-masked].
> To post to this group, send email to [email-masked].
> Visit this group at http://groups.google.com/a/vrs.io/group/io/.

---

From: Grant Beckmann <[email-masked]>
Date: Tue, 10 Mar 2015 00:52:57 +0000

The FCC rules are clear. The IP Address needs to be the user's public address (e.g. their home, business). No US provider of IP Relay services can be compensated for a call without the public address.

-gb

-----Original Message-----
From: Scot Brooksby [mailto:[email-masked]] 
Sent: Monday, March 09, 2015 4:25 PM
To: [email-masked]
Cc: [email-masked]; Paul Kyzivat
Subject: RE: [VRS Interop] Re: [dispatch] New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt

Cullen,

Thanks,
Scot

Scot Brooksby
Engineering Director, Architecture and Infrastructure Sorenson Communications

> Subject: Re: [dispatch] New Version Notification for 
> draft-kyzivat-dispatch-trs- call-info-purpose-00.txt
> Given the lack of any security around this and the TRS-5 requirement, 
> I wonder if one can just look at the via list and use that?
> 
> Video Relay Service in the US, and to the FCC that sponsors that 
> service. The Intro section explains this.
> >
> I don't anticipate that it needs time in Dallas. IIUC documents of 
> this sort are often AD sponsored.
> >
> > 	Thanks,
> > 	Paul
> >
> > Subject: New Version Notification for 
> > draft-kyzivat-dispatch-trs-call-info-
> purpose-00.txt
> > A new version of I-D, 
> > draft-kyzivat-dispatch-trs-call-info-purpose-00.txt
> > URL: 
> > http://www.ietf.org/internet-drafts/draft-kyzivat-dispatch-trs-call-
> > info-
> purpose-00.txt
> > Status: 
> > https://datatracker.ietf.org/doc/draft-kyzivat-dispatch-trs-call-inf
> > o-
> purpose/
> > Htmlized: 
> > http://tools.ietf.org/html/draft-kyzivat-dispatch-trs-call-info-
> purpose-00
> >
> >
> > Abstract:
> > Please note that it may take a couple of minutes from the time of 
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> >
> >
> You received this message because you are subscribed to the Google 
> Groups "VRS Interop" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to [email-masked].

--
You received this message because you are subscribed to the Google Groups "VRS Interop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
To post to this group, send email to [email-masked].
Visit this group at http://groups.google.com/a/vrs.io/group/io/.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 11 Mar 2015 00:16:07 +0000

That's very helpful - thank you 

> On Mar 9, 2015, at 3:25 PM, Scot Brooksby <[email-masked]> wrote:
> 
> Cullen,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Mar 2015 12:21:06 -0400

Cullen,

> First of all what IP. The IP of their phone behind their linksys nat? the public IP of the TURN server? the VPN? None of these are a viable way to authenticate that the user should receive this ser…

The address the FCC is interested in is the public IP of the user's 
device as seen by the VRS provider that the device connects to. The 
specifics depend on how the device connects to that provider. This gets 
complicated because the provider the device connects to may not be the 
provider that actually provides the reimbursable service.

> Given the lack of any security around this and the TRS-5 requirement, I wonder if one can just look at the via list and use that?

The actual IP of the device may not be in the via list.
It could be an H.323 endpoint that is being gatewayed by the default 
provider. (This will be common initially.)

> If we do proceed with this, I don't think the call-info is the appropriate place to put it. I think a new header would be the right thing.

We considered this, and thought that Call-Info was a more appropriate 
choice. But either is acceptable to us.

> Can you provide a pointer to the actually FCC rules for this?

Already done in a prior reply.

> If the goal is purely to check the user is in the US, then having the VRS check that they were sending media to an IP address inside the US seems like it would be a better solution.

Perhaps, if the FCC agreed. Maybe it could be done as an interpretation.
But it may also not be visible due to media relaying by the default 
provider.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Mar 2015 14:03:09 -0400

> We considered this, and thought that Call-Info was a more appropriate choice. But either is acceptable to us.
It is, exactly, information about the call, but I agree that a new header is an acceptable solution.

> But it may also not be visible due to media relaying by the default provider.
> 
Yeah, ubiquitous use of SBCs pretty much makes any addresses seen by the recipient a non-starter.
Please also note that the providers want the check to be the responsibility of the provider who is actually providing the interpreter service, and they explicitly support the “dial around” case that requires this work.

While a VPN would fool the check, any form of NAT on an ISP or home network is fine.  Like anything else, this check merely increases the cost of fraud, it doesn’t stop it.

I also point out that use can be restricted to a private networks (the one that interconnects providers).  It’s pretty much in everyone’s interests to strip the header if the call goes outside the domain of interest.  We can make that text as strict as we want.