Subject: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 19 May 2016 12:17:48 +0000

I did a reread of the INFO RFC last night in respect of the above draft, and came to the following conclusions.

1)	Any usage of the INFO method requires a full Info package definition. While there are various mentions of legacy usage, the draft is not trying to follow that direction, and in any case I am not convinced new registrations of relevant usage would be allowed down that route. So if the draft is to attempt to use the INFO method, it should formally define that method.

2)	The INFO RFC lays down clear instructions for the reviewer of the INFO package definition before it can be registered. In my view the current ecrit-ecall document would not pass that review.

3)	The INFO RFC makes no reference to transfer of data outside of the INFO method itself. My understanding is that the negotiation of the Info package within the Info-Package header field set to 'emergencyCallData.eCall' relates only to the data transferred in the INFO method using a conformant Info package definition. There therefore needs to be a discussion about what forms the negotiation mechanism for other information transferred, for example in the INVITE request, or other methods of the dialog, if such transfer is needed, and for it to be clearly documented.

4)	As indicated in 3), the INFO RFC does not expect data outside the Info package itself, and therefore nothing is stated there about the correlation of data between an application tagging things onto the methods of the dialog, and the application using the Info package.

5)	The INFO RFC allows for multiple Info packages to be used on the same dialog. There needs to be careful review to ensure that this capability is not compromised either in regard to the existing Info packages, or to new ones, particularly in regard to the assumed correlation between data in the Info package, and data transferred elsewhere in the dialog. I'd note that the draft would appear to sanction the inclusion of data in INFO methods belonging to entirely unrelated Info packages.

I would note that I am beginning to question whether there needs to be any transfer of data in the INVITE request. Transfer only within the INFO package after the response to the INVITE request is exchanged would still meet the 3GPP stage 1 requirements (see 22.101 release 14), and the whole document would be significantly simpler. None of the contents of the MSD is used for routeing the emergency call. This is without going into discussion about whether transfer using the signalling bearer, or some bearer negotiated using the SDP, is more appropriate. 

Regards

Keith Drage