Subject: Re: [Ecrit] Multipart with INFO

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Aug 2016 06:14:00 +0000

Hi Roland,

>>The question is whether the INFO request itself, and the MSD content
>>transported in the INFO request, are >associated with the same
>>"application" (ecall), and whether the MSD therefore must be sent using
>>an Info >Package, as stated in 6086.
>
>Discussing this all the time I'm wondering if we cannot come up with some
>text describing the "eCall" use case when using INFO with additional data
>for the eCall scenario. And make it clear that the application has to
>correlate the information.
>I think all other cases are out of scope.
>
>Or I'm wrong?

I don’t know, because I’m not sure I understood your comment :)

The point is that, when the content (MSD) is associated with the INFO
“application” (ecall), the content has to be associated with an Info
Package.

Regards,

Christer

>
>-----Ursprüngliche Nachricht-----
>Von: Ecrit [mailto:[email-masked]] Im Auftrag von Christer
>Holmberg
>Gesendet: Dienstag, 23. August 2016 18:28
>An: Brian Rosen; Drage, Keith (Nokia - GB)
>Cc: ECRIT
>Betreff: Re: [Ecrit] Multipart with INFO
>
>Hi,
>
>>The notion authors have proposed is that we create a command channel for
>>mid call communications between devices and PSAPs using INFO.  That
>>requires an INFO >package.  We can, however, make one INFO package that
>>defines this protocol and use it for multiple instances of devices
>>communicating with PSAPs, at least those that >have a simple request
>>update command.
>
>Correct.
>
>>We started this entire set of documents to manage sending of data from
>>devices to PSAPs.  eCall is one example, an alarm is another.   In most
>>cases, the initial data >accompanies the INVITE.
>>If there is an update, the device can decide to send it.  It is also
>>possible that the PSAP can request it.   Different devices have
>>different data.
>
>Correct.
>
>>No one has argued that the data sent with the INVITE is carried as
>>Additional Data, requiring a schema and a token registered with IANA.
>
>Correct. The agreement has been to use the mechanism defined in
>Additional Data for transporting the data in INVITE.
>
>> We’re arguing that the character of the data doesn’t change and the
>> schema of the data doesn’t change when you send it mid call, and it
>>doesn’t matter what message you attach it to, it’s Additional Data.
>>What we need INFO for is the
>> request/response command channel.   You send an INFO with a request
>>using an INFO package conforming to 6086.
>> You may get a response to the request (in another INFO). That’s the
>> INFO transaction and it satisfies all the requirements of 6086.  6086
>> isn’t a straightjacket.  I’m happy to go get sippcore to tell us the
>>obvious: we can send a Call-Info with a CID and a body, no matter what
>>the relationship between the INFO and the Call-Info are.  Do you want me
>>to ask for that?
>
>First, I'm happy to take this to SIPCORE (I already suggested that
>earlier).
>
>However, simply asking "Can we send a Call-Info with a CID and a body"
>isn't very useful.
>
>The question is whether the INFO request itself, and the MSD content
>transported in the INFO request, are associated with the same
>"application" (ecall), and whether the MSD therefore must be sent using
>an Info Package, as stated in 6086.
>
>> We want the MSD outside the INFO package because it’s Additional Data
>> and should be carried with a Call-Info pointing to the MIME type and
>>schema registered for Additional Data, just like in the INVITE.
>>
>> We want the INFO package for its command (send the MSD) and response
>> (ACK).  That can only happen mid-call, so INFO is appropriate.  It’s a
>> well defined INFO package, and it satisfies all the requirements of
>> 6068.  The same idea would work with any device that needs some kind
>> of command structure.  The example I gave was “send elevators to
>> ground floor”.  That would need a new INFO package because the command
>>is different.  The elevator status would be Additional Data, and would
>>be sent in a body pointed to by the Call-Info, just like it would in the
>>INVITE: same MIME type, same Content-Disposition.  But if I had a
>>container that sent a leak alarm, and that’s all it can do, using the
>>eCall INFO package to request an update of its data would work fine with
>>no changes.
>
>But INFO is not just like the INVITE. 6086 defines rules for how to
>transport content using INFO, and Additional Data cannot override those
>rules.
>
>>Using the INFO for command/control and Additional Data for the data is
>>clean and makes sense.  It allows us to reuse the INFO package for
>>other simple devices, and create others for more complex devices.  It
>>makes processing at the PSAP simpler, because the data comes the same
>>way whether it’s at the beginning of the call, it comes unsolicited or
>>it comes as a response to a command to send it.
>
>I am not sure I understand. You don't have to support the MSD Info
>Package in order to use the command/control protocol - it's defined
>separately, outside the MSD Info Package. You can use the protocol in
>whatever Info Package you want - and if you don't use INFO you don't even
>have to define an Info Package in order to use it.
>
>Regards,
>
>Christer
>
>
>Brian
>
>
>> On Aug 22, 2016, at 6:05 PM, Drage, Keith (Nokia - GB)
>><[email-masked]> wrote:
>> 
>> I'm afraid I see somewhat muddled thinking here, and I am sure it is
>>not mine.
>> 
>> We have already agreed for the use case of ecall, that the transfer of
>>data outside of a call control message using INFO requires the creation
>>of an Info package.
>> 
>> Following that use case, and using exactly the same argument, then any
>>other use case requiring to use INFO to transfer data would create
>>another Info package for the transfer of that data.
>> 
>> While theoretically, an argument might apply that it is valid to use
>>additional data in an INFO message, I cannot conceive of a use case
>>where only there in addition to the ecall Info package, and never
>>required at any other time. If it is required at any other time, then
>>the separate Info package must exist, and therefore if it exists, it
>>should be used for all the transfers outside of call control messages.
>>Conversely, if it is only there when ecall transfer exists, and never
>>outside it, I wonder why it is not part of the ecall Info package.
>> 
>> The only exception I can see to this is where some other preexisting
>>linking mechanism exists, such as Geolocation, but even this in my mind
>>causes issues.
>> 
>> Regards
>> 
>> Keith
>> 
>> -----Original Message-----
>> From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
>> Sent: 19 August 2016 23:53
>> To: Christer Holmberg; ECRIT
>> Subject: Re: [Ecrit] Multipart with INFO
>> 
>> On 8/19/16 6:36 PM, Christer Holmberg wrote:
>>> Hi,
>>> 
>>>>>>>>>> The discussion on ecall has become quite heated, with people
>>>>>>>>>> dug in on all sides. Can we calm it down a bit?
>>>>>>>>>> 
>>>>>>>>>> IMO a couple of different approaches have been described that
>>>>>>>>>> would work and not violate any specs. The differences between
>>>>>>>>>> these reflect differences of philosophy and taste.
>>>>>>>>> 
>>>>>>>>> I don¹t think we have an agreement on the
>>>>>>>>> would-not-violate-any-specs part. We clearly have different
>>>>>>>>>views on what is allowed by RFC 6086.
>>>>>>>>> 
>>>>>>>>> But, I do agree we need to try to figure out how to move forward.
>>>>>>>> 
>>>>>>>> OK. Maybe we should start there.
>>>>>>>> 
>>>>>>>> I guess there is some dispute on whether it is valid for an INFO
>>>>>>>> message to contain a multipart body, where one part contains the
>>>>>>>> info package
>>>>>>>> (C-D: info-package) and another part (C-D: by-reference) is
>>>>>>>> referenced by a cid: uri in some sip header field.
>>>>>>>> 
>>>>>>>> In my mind there is no question that this is valid. Do you
>>>>>>>> disagree, and if so, on what basis?
>>>>>>> 
>>>>>>> The dispute is whether a message body must be associated with an
>>>>>>> Info Package.
>>>>>>> 
>>>>>>> In my view:
>>>>>>> 
>>>>>>> - RFC 6086 allows bodies not associated with an Info Package in
>>>>>>> INFOs in order to be backward compatible with existing pre-6086
>>>>>>>INFO usages.
>>>>>>> - Any NEW usage MUST be associated with an Info Package. Sending
>>>>>>> of MSD is a new INFO usage.
>>>>>> 
>>>>>> I disagree. I find the following in 6086:
>>>>>> 
>>>>>>      NOTE: An INFO request can also contain other body parts that
>>>>>>are
>>>>>>      meaningful within the context of an invite dialog usage but are
>>>>>>      not specifically associated with the INFO method and the
>>>>>>      application concerned.
>>>>> 
>>>>> So, you are saying that the MSD is not associated with the ecall
>>>>>application???
>>>>> 
>>>>> RFC 6086 also says:
>>>>> 
>>>>> 	"Any new usage MUST use the Info Package mechanism defined in this
>>>>>       	specification, since it does not share the issues associated
>>>>>with
>>>>>       	legacy INFO usage, and since Info Packages can be registered
>>>>>with
>>>>>       	IANA."
>>>>> 
>>>>> And, in my opinion, sending of MSD *is* part of the new INFO usage.
>>>>>It's not something else that we add to the INFO.
>>>>> 
>>>>> Otherwise, why did we do RFC 6086 in the first place? We can just
>>>>>allow people to use - and standardize such usage - as in the past,
>>>>>with all the problems associated, just >> by saying the content is
>>>>>not associated with the application...
>>>> 
>>>> We did 6086 so that the usage if INFO to carry associated body parts
>>>>could be negotiated.
>>> 
>>> You don't need 6086 to indicate what body parts you support. There is
>>>a SIP header field for that.
>>> 
>>> We defined 6086 so that you could define and indicate the semantics
>>>associated with the INFO request (including body parts), and to
>>>negotiate support of processing that semantics.
>>> 
>>>> IMO if something is in the message, but not in the info-package body
>>>> part, then it isn't specifically part of the INFO usage. For
>>>>instance, any random header field that you happen to include isn't.
>>> 
>>> MSD is not "something random that you happen to include" in an INFO
>>>associated with the ecall application.
>>> 
>>> Or, again, are you saying that MSD is not associated with the ecall
>>>application?
>> 
>> I"m saying that I don't know anything about an ecall *application*. I
>>agree there might be one, but we aren't defining that. I do know the MSD
>>is associated with a call-info header field. I can potentially put that
>>call-info in any message I like (that permits call-info).
>> 
>> If there happens to be an ecall application, then the MSD might indeed
>> end up at that application. I would expect that the application will
>> be
>> *loosely* coupled to the sip session. Lots of other things may happen
>>in that session that may or may not be anticipated by the application.
>> Those things may be processed by other UA application software. So the
>>ecall application is just one *user* of the sip session.
>> 
>> Of course the application environment may constrain the possibilities
>>in some way. But I think that is outside of our scope here.
>> 
>> 	Thanks,
>> 	Paul
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Aug 2016 14:07:48 -0400

Christer,

>>> an Info Package, as stated in 6086.
[snip]
> “application” (ecall), the content has to be associated with an Info

You keep making this argument and I totally fail to understand it. I 
think your are trying to read more into "application" than makes sense 
to me.

When the ecall first arrives, there is no info package, but there *is* 
an MSD in additional-data. That MSD presumably gets delivered to where 
it needs to go. Call that an "ecall application" if you like.

Then we have an info package that is used in that call to convey some 
further information relevant in the context of the call. This also goes 
where it needs to go - presumably the "ecall application". Thus we have 
two different means of conveying information to that application.

If there is subsequently a reINVITE, presumably it would be acceptable 
to attach MSD additional-data to it and that would also go to the 
application.

So why would it somehow be wrong to attach MSD additional-data to an INFO?

(If it makes you happier, feel free to consider that there is one 
application that is dedicated to the ecall info package, and another 
application that is dedicated to MSD additional data, and a higher level 
application that ties the two together.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Aug 2016 18:28:04 +0000

Hi,

>>>> "application" (ecall), and whether the MSD therefore must be sent 
>>>> using an Info Package, as stated in 6086.
>>[snip]
>> "application" (ecall), the content has to be associated with an Info 
>> Package.
>
> You keep making this argument and I totally fail to understand it. I think your are trying to read more into "application" than makes sense to me.
>
> When the ecall first arrives, there is no info package, but there *is* an MSD in additional-data. That MSD presumably gets delivered
> to where it needs to go. Call that an "ecall application" if you like.
>
> Then we have an info package that is used in that call to convey some further information relevant in the context of the call. This 
> also goes where it needs to go - presumably the "ecall application". Thus we have two different means of conveying information to that application.

Yes. But we KNEW that when we did 6086. We were aware of that fact that, eventhough the same MIME type can be used for conveying data in INVITE and INFO, there will be different mechanisms to convey the same data in INVITEs and INFOs.

>If there is subsequently a reINVITE, presumably it would be acceptable to attach MSD additional-data to it and that would also go to the application.

Yes.

>So why would it somehow be wrong to attach MSD additional-data to an INFO?

Because RFC 6086 defines how to convey data associated with the "application". One may not like it, but that's what it says, and you know the reason why it says so.

>(If it makes you happier, feel free to consider that there is one application that is dedicated to the ecall info package, and another application that is dedicated to MSD >additional data, and a higher level application that ties the two together.)

I don't want to find ways to get around using an Info Package. I think MSD is a school book example of Info Package usage.

Saying that the request for MSD is associated with the ecall application, but the delivery of the requested MSD isn't, is REALLY farfetched in my opinion. It's the ecall application that requests the MSD, and it's the ecall application that consumes the MSD.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Aug 2016 14:52:56 -0400

> Saying that the request for MSD is associated with the ecall application, but the delivery of the requested MSD isn't, is REALLY farfetched in my opinion. It's the ecall application that requests t…

This all begs the question of what *the* application is. It presumes 
there is exactly one. Can you point me to the specific text in 6086 that 
leads you to think there is such a rule? (I looked and couldn't find it.)

If you want to rely religiously to that, then you also ought to be 
arguing that if INFO is going to be used, then INFO should be the *only* 
thing that is used for that application. Hence an additional-data should 
not be used at all in the same call with it.

You could make an alternative proposal for ecall that takes that 
philosophy. It would be aesthetically pure. If there is no need to have 
MSD data sooner than it could arrive in an INFO then I think that would 
be perfectly reasonable. But I have yet to see such a proposal.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Aug 2016 19:22:23 +0000

Hi,

>>>>>> The question is whether the INFO request itself, and the MSD 
>>>>>> content transported in the INFO request, are associated with the 
>>>>>> same "application" (ecall), and whether the MSD therefore must be 
>>>>>> sent using an Info Package, as stated in 6086.
>>>> [snip]
>>>> The point is that, when the content (MSD) is associated with the 
>>>> INFO "application" (ecall), the content has to be associated with an 
>>>> Info Package.
>>>
>>> When the ecall first arrives, there is no info package, but there 
>>> *is* an MSD in additional-data. That MSD presumably gets delivered to where it needs to go. Call that an "ecall application" if you like.
>>>
>>> further information relevant in the context of the call. This also goes where it needs to go - presumably 
>>> the "ecall application". Thus we have two different means of conveying information to that application.
>>
>> Yes. But we KNEW that when we did 6086. We were aware of that fact that, eventhough the same MIME type 
>> can be used for conveying data in INVITE and INFO, there will be different mechanisms to convey the same data in INVITEs and INFOs.
>>
>>> (If it makes you happier, feel free to consider that there is one application that is dedicated to the ecall info package, and another 
>>> application that is dedicated to MSD >additional data, and a higher level application that ties the two together.)
>>
>> Saying that the request for MSD is associated with the ecall application, but the delivery of the requested MSD isn't, is REALLY
>> farfetched in my opinion. It's the ecall application that requests the MSD, and it's the ecall application that consumes the MSD.
>
> This all begs the question of what *the* application is. It presumes there is exactly one. Can you point me to the specific 
> text in 6086 that leads you to think there is such a rule? (I looked and couldn't find it.)

I didn't say 6086 mandates only one application. I said that the request/control protocol, the MSD, and the INFO used to carry those, are all associated with the ecall application.

And, EVEN if we did come up with another application X for conveying MSD, and application X sends an INFO with MSD only, it would still have to use an Info Package, because the INFO and the MSD content is associated with application X.

My point is: if we allow people to word smith their way around using Info Packages, claiming that the content in the INFO is not associated with the application sending the INFO (which is some cases may be true, btw, and then we do talk about valid piggy backing cases), we can as well throw away 6086 (and all the years of work to come up with it)... 

> If you want to rely religiously to that, then you also ought to be arguing that if INFO is going to be used, then INFO should 
> be the *only* thing that is used for that application. Hence an additional-data should not be used at all in the same call with it.

I don't say that. RFC 6086 only covers INFO, but doesn't forbid the same information from being transported also using other SIP methods - using whatever mechanisms.

And, just to be clear: I have no problem using the Additional Data mechanism for sending MSD in INVITEs.

> You could make an alternative proposal for ecall that takes that philosophy. It would be aesthetically pure. If there is no need to 
> have MSD data sooner than it could arrive in an INFO then I think that would be perfectly reasonable. But I have yet to see such a proposal.

I support being able to send MSD in INVITE, so I am not going to make such proposal :)

Regards,

Christer

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Aug 2016 09:23:43 -0400

For those of you that are not subscribed to the sipcore list, I have raised the question of whether the language of 6086 would prohibit the use of Call-Info to carry the MSD.

We’ll report the conclusion back to ecrit.

Brian

> On Aug 24, 2016, at 3:22 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>