Subject: Re: [Ecrit] New Call-Info header proposed for top-level providerInfo - draft-ietf-ecrit-additional-data-22

From: Roger Marshall <[email-masked]>
Date: Mon, 5 May 2014 19:25:37 +0000

Sending to Ecrit only this time (argh)

I'd like to propose that a new Call-Info header - something to be added to the draft based on some early implementation experience in NENA and NG9-1-1.

In addition to the Call-Info header usage already defined in the draft, I propose that we require the addition of a single new Call-Info header that includes a purpose parameter to denote the service provider that handed off the call last, making this provided-by information easily accessible for routing reasons without requiring the elements along the path to dig out the value from the PIDF-LO - whether from the MIME body part of from a by-Reference retrieval operation.

We would want to retain Call-Info with purpose=EmergencyCallData.ProviderInfo to carry the "full XML" (either byV or byR), one per Access Network Provider, Service Provider, etc (as described in the draft)

And then add functionality for our newly proposed Call-Info header with purpose=nena-ProviderID.  To clarify the intent, this new purpose=nena-ProviderID is for the Telecom Provider, which is described in section 3.1.4 of the additional-data draft as "Calling or origination telecom SP", of which there can only be one.   So multiple Call-Info with purpose=nena-ProviderID would not make sense.  To help clarify, I think we should rename the purpose to be more like purpose=nena-TelecomProviderID, so that the value of the purpose helps clarify.

In the long run signaling should carry both the Call-Info with purpose=EmergencyCallData.ProviderInfo (either byR or byV) with the full XML, and then exactly one with purpose=nena-TelecomProviderID as proposed.

Note that for the purpose=EmergencyCallData.ProviderInfo there can be multiple of those Call-Info (per the draft), so that each "provider" in the path can attach their own data (as described in the draft).  Also note that for legacy carrier where ESInet is constructing the SIP for the 911, there will probably be only one.

What do people think?

-roger.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 5 May 2014 14:20:14 -0700

Hi Roger,

Can you explain a bit more about the "early implementation experience 
in NENA and NG9-1-1" that lead to the proposal?

You've obviously been thinking about it for some time, but the rest 
of us are just hearing about it now, so it would be helpful to 
provide some background.

At 7:25 PM +0000 5/5/14, Roger Marshall wrote:

>>  I'd like to propose that a new Call-Info header - something to be 
>> added to the draft based on some early implementation experience 
>> in NENA and NG9-1-1.
>>
>>  In addition to the Call-Info header usage already defined in the 
>> draft, I propose that we require the addition of a single new 
>> Call-Info header that includes a purpose parameter to denote the 
>> service provider that handed off the call last, making this 
>> provided-by information easily accessible for routing reasons 
>> without requiring the elements along the path to dig out the value 
>> from the PIDF-LO - whether from the MIME body part of from a 
>> by-Reference retrieval operation.
>>
>>  We would want to retain Call-Info with 
>> purpose=EmergencyCallData.ProviderInfo to carry the "full XML" 
>> (either byV or byR), one per Access Network Provider, Service 
>> Provider, etc (as described in the draft)
>>
>>  And then add functionality for our newly proposed Call-Info header 
>> with purpose=nena-ProviderID.  To clarify the intent, this new 
>> purpose=nena-ProviderID is for the Telecom Provider, which is 
>> described in section 3.1.4 of the additional-data draft as 
>> "Calling or origination telecom SP", of which there can only be 
>> one.   So multiple Call-Info with purpose=nena-ProviderID would 
>> not make sense.  To help clarify, I think we should rename the 
>> purpose to be more like purpose=nena-TelecomProviderID, so that 
>> the value of the purpose helps clarify.
>>
>>  In the long run signaling should carry both the Call-Info with 
>> purpose=EmergencyCallData.ProviderInfo (either byR or byV) with 
>> the full XML, and then exactly one with 
>> purpose=nena-TelecomProviderID as proposed.  
>>
>>  Note that for the purpose=EmergencyCallData.ProviderInfo there can 
>> be multiple of those Call-Info (per the draft), so that each 
>> "provider" in the path can attach their own data (as described in 
>> the draft).  Also note that for legacy carrier where ESInet is 
>> constructing the SIP for the 911, there will probably be only one.
>>
>>  What do people think?
>>
>>  -roger.
>>
>  CONFIDENTIALITY NOTICE: The information contained in this message 
> may be privileged and/or confidential. If you are not the intended 
> recipient, or responsible for delivering this message to the 
> intended recipient, any review, forwarding, dissemination, 
> distribution or copying of this communication or any attachment(s) 
> is strictly prohibited. If you have received this message in error, 
> please notify the sender immediately, and delete it and all 
> attachments from your computer and network.
>
>
>  _______________________________________________
>  Ecrit mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ecrit

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I have seen the free market, and its face is Bill Gates'
                                        --Jay S. Laefer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 6 May 2014 10:46:43 +0000

We seem to be drifting further from what the definition of the Call-Info header field is for, which is to exchange information between two end users.

If this is the mechanism that is required, then it raises question on whether the Call-Info header field should have been used in the first place.

Regards

Keith 

> -----Original Message-----
> From: Ecrit [mailto:[email-masked]] On Behalf Of 
> Randall Gellens
> Sent: 05 May 2014 22:20
> To: Roger Marshall; [email-masked]
> Subject: Re: [Ecrit] New Call-Info header proposed for 
> top-level providerInfo - draft-ietf-ecrit-additional-data-22
> 
> Hi Roger,
> 
> Can you explain a bit more about the "early implementation 
> experience in NENA and NG9-1-1" that lead to the proposal?
> 
> You've obviously been thinking about it for some time, but 
> the rest of us are just hearing about it now, so it would be 
> helpful to provide some background.
> 
> 
> >> added to the draft based on some early implementation 
> experience in 
> >> NENA and NG9-1-1.
> >>
> >> provided-by information easily accessible for routing 
> reasons without 
> >> requiring the elements along the path to dig out the value 
> from the 
> >> PIDF-LO - whether from the MIME body part of from a by-Reference 
> >> retrieval operation.
> >>
> "Calling 
> >> or origination telecom SP", of which there can only be
> >> purpose to be more like purpose=nena-TelecomProviderID, so 
> that the 
> >> value of the purpose helps clarify.
> >>
> >> purpose=EmergencyCallData.ProviderInfo (either byR or byV) 
> with the 
> >> full XML, and then exactly one with 
> >> "provider" in the path can attach their own data (as 
> described in the 
> >> draft).  Also note that for legacy carrier where ESInet is 
> >  CONFIDENTIALITY NOTICE: The information contained in this 
> message may 
> > be privileged and/or confidential. If you are not the intended 
> > recipient, or responsible for delivering this message to 
> the intended 
> > recipient, any review, forwarding, dissemination, distribution or 
> > copying of this communication or any attachment(s) is strictly 
> > prohibited. If you have received this message in error, 
> please notify 
> > the sender immediately, and delete it and all attachments from your 
> > computer and network.
> >
> >
> -------------- Randomly selected tag: --------------- I have 
> seen the free market, and its face is Bill Gates'
>                                         --Jay S. Laefer
>