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

That's very helpful - thank you 


> On Mar 9, 2015, at 3:25 PM, Scot Brooksby <SBrooksby@sorenson.com> wrote:
> 
> 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 <fluffy@cisco.com>
>> To: Paul Kyzivat <pkyzivat@alum.mit.edu>
>> CC: dispatch@ietf.org <dispatch@ietf.org>
>> 
>> 
>> 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 <pkyzivat@alum.mit.edu> 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: internet-drafts@ietf.org
>>> To: Paul Kyzivat <pkyzivat@alum.mit.edu>,        "Paul Kyzivat"
>> <pkyzivat@alum.mit.edu>
>>> 
>>> 
>>> 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
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>> 
>> 
>> 
>> 
>> 
>> --
>> 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 io+unsubscribe@vrs.io.
>> To post to this group, send email to io@vrs.io.
>> Visit this group at http://groups.google.com/a/vrs.io/group/io/.