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

Cullen,

On 3/9/15 10:58 AM, Cullen Jennings wrote:
>
> 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.

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

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