Subject: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 5 Aug 2016 11:15:24 +0000

Hello,

COMMENT:

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Inclusion of Call-Info header field with purpose=emergencyCallData.eCall.MSD or purpose=emergencyCallData.eCall.control in requests and responses does not seem to bring any value. It seems to only waste radio resources.

For Call-Info with purpose=emergencyCallData.eCall.MSD included in the initial INVITE request:

- if this is meant to be used by a proxy for routing of the eCall emergency call to a PSAP supporting eCall emergency call, then this seems to be redundant to the eCall URN included in the Request-URI and the Recv-Info header field containing eCall specific info package (emergencyCallData.eCall.MSD).

- if this is meant to be used by UAS (i.e. PSAP), then according to RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all the bodies of the INVITE request not marked with Content-Disposition: ...; handling=optional are understood. So, application/emergencyCallData.eCall.MSD+per MIME body will anyway be found by UAS during the INVITE request processing.

For Call-Info with purpose=emergencyCallData.eCall.control included in a response to the initial INVITE request

- no routing decisions are done by proxies when receiving a response to the initial INVITE request so this does not seem to have any value for the proxies

- UAC includes Accept with supported MIME types in INVITE request so why would UAS send any MIME body not wished by the UAC?

For Call-Info with purpose=emergencyCallData.eCall.control included in the INFO request

- no routing decisions are done by proxies when receiving an in-dialog request so this does not seem to have any value for the proxies

- support of info package emergencyCallData.eCall.MSD in the call implies that either application/EmergencyCallData.eCall.control+xml MIME body or application/emergencyCallData.eCall.MSD+per MIME body is included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway needs to check that all the bodies of the INFO request not marked with Content-Disposition: ...; handling=optional are understood. So, application/EmergencyCallData.eCall.control+xml MIME body or application/emergencyCallData.eCall.MSD+per MIME body will anyway be found by UAS during the INFO request processing.

//////////////////////////////////////////////////////////////////////////////

PROPOSED SOLUTION to COMMENT

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Remove insertion of Call-Info header field.

//////////////////////////////////////////////////////////////////////////////

Kind regards

Ivo Sedlacek

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 5 Aug 2016 10:43:04 -0400

Ivo,

IIUC, you are saying that the Call-Info that refers to the body is 
unnecessary because the recipient will know what to do with the body 
even in the absence of the Call-Info. Is that right?

This assumption mixes up two things:
- understanding a body syntactically
- understanding *why* the body is present and how it should be used.

Historically, processing of body parts in sip was very poorly defined. 
Initially the only body of interest was SDP, so how one might process 
other bodies or body parts was not well considered. Eventually this 
started to be a liability, so RFC5621 was published to clarify it.

Processing of body parts is governed by a complex interaction between 
Content-Type, Content-Disposition, Content-ID.

So the call-info header indicates the reason that body is being 
included. I realize that there is one predominant reason for doing so, 
but that is not the only possible reason. (E.g., it might be included as 
context in an intended discussion about problems handling a call in the 
past.)

If all the handling of the call is coded in a special purpose way, 
solely for the emergency call path, then alternatives may be of no 
concern. But ideally the call will largely be handled via standard 
library code that is also used for other call paths and other message 
processing. So processing body parts in a "standard" way, rather than 
special casing, is desirable.

	Thanks,
	Paul

On 8/5/16 7:15 AM, Ivo Sedlacek wrote:
> Inclusion of Call-Info header field with
> purpose=emergencyCallData.eCall.MSD or
> purpose=emergencyCallData.eCall.control in requests and responses does
> not seem to bring any value. It seems to only waste radio resources.
>
>
>
> - if this is meant to be used by a proxy for routing of the eCall
> emergency call to a PSAP supporting eCall emergency call, then this
> seems to be redundant to the eCall URN included in the Request-URI and
> the Recv-Info header field containing eCall specific info package
> (emergencyCallData.eCall.MSD).
>
> - if this is meant to be used by UAS (i.e. PSAP), then according to
> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all the
> bodies of the INVITE request not marked with Content-Disposition: ...;
> handling=optional are understood. So,
> application/emergencyCallData.eCall.MSD+per MIME body will anyway be
> found by UAS during the INVITE request processing.
>
>
>
> - no routing decisions are done by proxies when receiving a response to
> the initial INVITE request so this does not seem to have any value for
> the proxies
>
> - UAC includes Accept with supported MIME types in INVITE request so why
> would UAS send any MIME body not wished by the UAC?
>
>
>
> - no routing decisions are done by proxies when receiving an in-dialog
> request so this does not seem to have any value for the proxies
>
> - support of info package emergencyCallData.eCall.MSD in the call
> implies that either application/EmergencyCallData.eCall.control+xml MIME
> body or application/emergencyCallData.eCall.MSD+per MIME body is
> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway
> needs to check that all the bodies of the INFO request not marked with
> Content-Disposition: ...; handling=optional are understood. So,
> application/EmergencyCallData.eCall.control+xml MIME body or
> application/emergencyCallData.eCall.MSD+per MIME body will anyway be
> found by UAS during the INFO request processing.
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Aug 2016 15:14:44 +0000

Hi Paul,

In INFOs, the info package specification shall indicate WHY a message body is included. That was one of the main reason for doing the info package mechanism.

And, as Ivo also indicated, INFOs will be routed according to the established route set.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎05/‎08/‎2016 17:43
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

Ivo,

        Thanks,
        Paul

---

From: Brian Rosen <[email-masked]>
Date: Fri, 5 Aug 2016 11:17:19 -0400

Also, since ecall is a form of “additional data”, it should conform to the syntax for all the other additional data blocks that may be included in the call.

Brian

> On Aug 5, 2016, at 10:43 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Ivo,
> 
> IIUC, you are saying that the Call-Info that refers to the body is unnecessary because the recipient will know what to do with the body even in the absence of the Call-Info. Is that right?
> 
> Historically, processing of body parts in sip was very poorly defined. Initially the only body of interest was SDP, so how one might process other bodies or body parts was not well considered. Eventually this started to be a liability, so RFC5621 was published to clarify it.
> 
> Processing of body parts is governed by a complex interaction between Content-Type, Content-Disposition, Content-ID.
> 
> So the call-info header indicates the reason that body is being included. I realize that there is one predominant reason for doing so, but that is not the only possible reason. (E.g., it might be included as context in an intended discussion about problems handling a call in the past.)
> 
> If all the handling of the call is coded in a special purpose way, solely for the emergency call path, then alternatives may be of no concern. But ideally the call will largely be handled via standard library code that is also used for other call paths and other message processing. So processing body parts in a "standard" way, rather than special casing, is desirable.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 5 Aug 2016 12:49:54 -0400

On 8/5/16 11:14 AM, Christer Holmberg wrote:
> Hi Paul,
>
> In INFOs, the info package specification shall indicate WHY a message
> body is included. That was one of the main reason for doing the info
> package mechanism.
>

I didn't think this was about INFO. I agree that in INFO, as long as the 
body is properly marked as the package body for the INFO that a 
call-info pointing to it isn't needed, and not appropriate.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Aug 2016 19:39:20 +0000

Hi,

As far as I understand, usage of Call-Info is defined for both INVITE and INFO. I have not read the latest version of the draft, though, so please discard my comment if that's not the case.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎05/‎08/‎2016 19:49
To: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

        Thanks,
        Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Aug 2016 19:57:44 +0000

Hi Brian,

As far as I remember, additional data does not say anything about info packages. The text might be general, but whenever you are going to use an info package you must define an info package specification that describes the details associated with that info package.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Brian Rosen<mailto:[email-masked]>
Sent: ‎05/‎08/‎2016 18:17
To: Paul Kyzivat<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 5 Aug 2016 17:02:26 -0400

Sure.

But the INFO is a way to send additional data update in the middle of a session.

You don’t use it with the INVITE.

I’d like the mechanisms to be as similar as possible.

Brian

> On Aug 5, 2016, at 3:57 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Brian,
> 
> From: Brian Rosen <mailto:[email-masked]>
> To: Paul Kyzivat <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> > On Aug 5, 2016, at 10:43 AM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Ivo,
> > 
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
> >> 
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Aug 2016 22:06:02 +0000

Hi,

Unless you've defined an info package for sending additional data, you can't use INFO for doing it.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Brian Rosen<mailto:[email-masked]>
Sent: ‎06/‎08/‎2016 00:02
To: Christer Holmberg<mailto:[email-masked]>
Cc: Paul Kyzivat<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

Sure.

Brian

On Aug 5, 2016, at 3:57 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

Regards,

Christer

Brian

> On Aug 5, 2016, at 10:43 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
>
> Ivo,
>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Randall Gellens <[email-masked]>
Date: Fri, 5 Aug 2016 22:43:58 -0700

eCall makes use of the additional-data mechanism as defined in RFC 
7852.  This makes all data that's sent as part of an emergency call 
consistent.  Call-Info is used as defined in RFC 7852 for all data 
blocks sent as part of the emergency call.  It allows the PSAP (and 
ESInet where deployed) to know which data blocks are attached, and 
process those it is interested in.  The eCall draft is used by the 
car-crash draft, which covers NG-AACN in North America and other 
regions that don't use pan-European eCall.  This makes it simpler for 
multi-region (global) vehicles, and for common PSAP equipment. 
Especially in North America, carriers will add RFC 7852 data blocks 
(e.g., to identify the carrier).  I see value in having all data 
blocks be attached the same way.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I see in the near future a crisis approaching that unnerves me and
causes me to tremble for the safety of my country...corporations have
been enthroned and an era of corruption in high places will follow,
and the money of the country will endeavor to prolong its reign by
working upon the prejudices of the people until all wealth is
aggregated in a few hands and the Republic is destroyed.  I feel at
this moment more anxiety for the safety of my country than ever
before, even in the midst of war.
                                                    --Abraham Lincoln

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 8 Aug 2016 07:43:18 +0000

Hello Paul,

the comment explicitly referred to INVITE and to INFO.

Excerpts from the attached:

---------------

...

...

...

---------------

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 6:50 PM
To: Christer Holmberg; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

> And, as Ivo also indicated, INFOs will be routed according to the

> established route set.

I didn't think this was about INFO. I agree that in INFO, as long as the body is properly marked as the package body for the INFO that a call-info pointing to it isn't needed, and not appropriate.

                Thanks,

                Paul

> ----------------------------------------------------------------------

> To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings

> no value

> but that is not the only possible reason. (E.g., it might be included

> as context in an intended discussion about problems handling a call in

> the

>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

>> \\\\\\\\\

>> purpose=emergencyCallData.eCall.control in requests and responses

>> does not seem to bring any value. It seems to only waste radio resources.

>> For Call-Info with purpose=emergencyCallData.eCall.MSD included in

>> the initial INVITE request:

>> seems to be redundant to the eCall URN included in the Request-URI

>> and the Recv-Info header field containing eCall specific info package

>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all

>> the bodies of the INVITE request not marked with Content-Disposition:

>> ...; handling=optional are understood. So,

>> For Call-Info with purpose=emergencyCallData.eCall.control included

>> in a response to the initial INVITE request

>> - no routing decisions are done by proxies when receiving a response

>> to the initial INVITE request so this does not seem to have any value

>> for the proxies

>> - UAC includes Accept with supported MIME types in INVITE request so

>> why would UAS send any MIME body not wished by the UAC?

>> For Call-Info with purpose=emergencyCallData.eCall.control included

>> in the INFO request

>> - no routing decisions are done by proxies when receiving an

>> in-dialog request so this does not seem to have any value for the

>> proxies

>> implies that either application/EmergencyCallData.eCall.control+xml

>> MIME body or application/emergencyCallData.eCall.MSD+per MIME body is

>> needs to check that all the bodies of the INFO request not marked

>> with

>> /////////////////////////////////////////////////////////////////////

>> /////////

>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

>> \\\\\\\\\

>> /////////////////////////////////////////////////////////////////////

>> /////////

Ecrit mailing list

Subject: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value
From: Ivo Sedlacek <[email-masked]>
To: Roger Marshall <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 5 Aug 2016 11:15:24 +0000
List-Id: <ecrit.ietf.org>

Hello,

COMMENT:

Kind regards

Ivo Sedlacek

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Aug 2016 08:56:22 -0400

> the comment explicitly referred to INVITE and to INFO.

OK. My position is that call-info is proper to use in INVITE. It should 
not be necessary in INFO. Whether it is incorrect to use it in INFO is 
arguable either way.

	Thanks,
	Paul

>> To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Aug 2016 13:34:04 +0000

Hi,

It is allowed to include Call-Info in INFO - that's not the issue. The question is WHY we would mandate it.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎08/‎08/‎2016 15:56
To: Ivo Sedlacek<mailto:[email-masked]>; Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Aug 2016 10:16:20 -0400

> question is WHY we would mandate it.

I wasn't concerned with the general issue of call-info in INFO. (I can 
see how that might be meaningful in some cases, entirely unconnected to 
what is contained in the info body.)

What I'm questioning is including a call-info that references the 
package body in the INFO. In the current case that is at least 
redundant, since the definition of the INFO package should cover the 
semantics of how to process it. Whether it is *wrong* to use such 
redundancy may be arguable. I'm inclined to recommend against it, but I 
have no strong arguments to make in that regard.

	Thanks,
	Paul

> To: Ivo Sedlacek <mailto:[email-masked]>; Christer Holmberg
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Aug 2016 14:25:37 +0000

Hi,

If you are doing the same thing, using two different mechanisms, at the same time, you may end up in situations where the information is not matching, i.e. the call-info information is not aligned with the Info Package. Which takes precedence?

Or, what if the Call-Info headers, or parts of the mandated information, is missing? Should the receiver reject the INFO, or the content within, even if it doesn't have to?

Etc etc etc.

The less doors we open for ambiguity, misalignments and errors, the better... 

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 08 August 2016 17:16
To: Christer Holmberg <[email-masked]>; Ivo Sedlacek <[email-masked]>; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

> question is WHY we would mandate it.

I wasn't concerned with the general issue of call-info in INFO. (I can see how that might be meaningful in some cases, entirely unconnected to what is contained in the info body.)

What I'm questioning is including a call-info that references the package body in the INFO. In the current case that is at least redundant, since the definition of the INFO package should cover the semantics of how to process it. Whether it is *wrong* to use such redundancy may be arguable. I'm inclined to recommend against it, but I have no strong arguments to make in that regard.

	Thanks,
	Paul

> OK. My position is that call-info is proper to use in INVITE. It 
> should not be necessary in INFO. Whether it is incorrect to use it in 
> INFO is arguable either way.
>
>         Thanks,
>         Paul
>
>> I didn't think this was about INFO. I agree that in INFO, as long as 
>> the body is properly marked as the package body for the INFO that a