Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Sep 2016 08:53:56 +0000

Hi,

While I highly appreciate Dale¹s input on the INFO issue, it seems like we
won¹t get much wider input from the SIPCORE community.

So, in order to try to move forward, I would like to suggest a compromise
proposal of my own. From a SIP message structure perspective it¹s
basically what Dale has suggested (and what I assumed was already stated
in draft-ecall-11), but with a different approach when it comes to the
documenting.

First, the MSD is carried in an info package.

Second, the main text in draft-ecall talks about using the info package
mechanism for carrying the MSD in INFO. The main text does not talk about
using the additional data mechanism.

Third, and this is where my comprise proposal comes it, within the info
package specification we add some text saying that while the
semantics/context of the MSD MIME body is defined within the info package
specification, in order to be aligned with the sending of MSD in non-INFO
requests we use the content-disposition value reference-by and we include
the Call-Info header field, as defined by Additional Data, in the INFO
request.

That way, we make it clear that we are using the info package mechanism
for transporting MSD in INFO, but it still allows for usage of Call-Info
in INFO. 

Would people be ok with that?

INFO example:

Call-Info:   <cid:X>;purpose=emergencyCallData.eCall.MSD
Content-Type: multipart/mixed;boundary="theboundary"
Content-Disposition: info-package

--theboundary

Content-Type: application/emergencyCallData.eCall.MSD+per
Content-Dispostion: by-reference

<MSD content>

‹theboundary--

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 1 Sep 2016 11:52:04 -0400

Christer,

Your example is incomplete (e.g., multipart is specified but only one 
body part is shown), and I hesitate to comment without first seeing 
exactly what you mean. Can you please provide a complete example?

	Thanks,
	Paul

On 9/1/16 4:53 AM, Christer Holmberg wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Sep 2016 15:53:54 +0000

Hi,

>Your example is incomplete (e.g., multipart is specified but only one body part is >shown), and I hesitate to comment without first seeing exactly what you mean. Can >you please provide a complete example?

My example shows an INFO only carrying MSD, so it is no incomplete.

Regards,

Christer

On 9/1/16 4:53 AM, Christer Holmberg wrote:
> Hi,
>
> While I highly appreciate Dale¹s input on the INFO issue, it seems 
> like we won¹t get much wider input from the SIPCORE community.
>
> So, in order to try to move forward, I would like to suggest a 
> compromise proposal of my own. From a SIP message structure 
> perspective it¹s basically what Dale has suggested (and what I assumed 
> was already stated in draft-ecall-11), but with a different approach 
> when it comes to the documenting.
>
> Second, the main text in draft-ecall talks about using the info 
> package mechanism for carrying the MSD in INFO. The main text does not 
> talk about using the additional data mechanism.
>
> Third, and this is where my comprise proposal comes it, within the 
> info package specification we add some text saying that while the 
> semantics/context of the MSD MIME body is defined within the info 
> package specification, in order to be aligned with the sending of MSD 
> in non-INFO requests we use the content-disposition value reference-by 
> and we include the Call-Info header field, as defined by Additional 
> Data, in the INFO request.
>
> That way, we make it clear that we are using the info package 
> mechanism for transporting MSD in INFO, but it still allows for usage 
> of Call-Info in INFO.
>
> <theboundary--

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 1 Sep 2016 12:24:48 -0400

> My example shows an INFO only carrying MSD, so it is no incomplete.

Oh, sorry. I misunderstood what you were doing.

Yes, this is very much in the spirit of what Dale suggested. I think it 
is simply a degenerate form of it. IMO this is a valid combination of 
INFO and call-info.

So, using this approach, what would be your message sequence including 
the request for an update of MSD?

The prior approach was able to send the MSD on the response to the INFO 
that requested it, Or to send it attached to some message following that 
request. IIUC, in your approach here there will first be a response to 
the INFO request (no body) followed by another INFO in the other 
direction of the form you show here.

Presupposing that all this was valid, would it still be valid for UA to 
send some unsolicited message in the dialog (e.g., UPDATE) with an MSD 
as additional-data?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Sep 2016 16:32:00 +0000

Hi,

>>> Your example is incomplete (e.g., multipart is specified but only one body part is shown), and I 
>>> hesitate to comment without first seeing exactly what you mean. Can >you please provide a complete example?
>>
> Yes, this is very much in the spirit of what Dale suggested. I think it is simply a degenerate form of it. IMO this is a valid combination of INFO and call-info.

Correct. My suggestion will mostly impact how we document everything.

> So, using this approach, what would be your message sequence including the request for an update of MSD?
>
> The prior approach was able to send the MSD on the response to the INFO that requested it, Or to send it attached
> to some message following that request. IIUC, in your approach here there will first be a response to the INFO request 
> (no body) followed by another INFO in the other direction of the form you show here.

Correct. Formally we would be using an info package to carry the MSD, so the RFC 6086 rules apply (read: we only send MSD in INFO requests).

> Presupposing that all this was valid, would it still be valid for UA to send some unsolicited message in the dialog (e.g., UPDATE) with an MSD as additional-data?

I think is a separate question, not related to the INFO usage. But, to answer your question: in my opinion, if you are sending an UPDATE for whatever valid reason, I think it is ok to  include MSD as additional-data. But, I don't think one should send UPDATE just for the purpose of conveying MSD - for that one should use INFO.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 1 Sep 2016 14:14:31 -0400

OK, we are largely in agreement here. One comment inline.

> I think is a separate question, not related to the INFO usage. But, to answer your question: in my opinion, if you are sending an UPDATE for whatever valid reason, I think it is ok to  include MSD…

I agree it is a separate question.

IIUC UPDATE may be used as a noop, good for testing the liveness of the 
path and the other end, better in some respects than OPTIONS. If 
somebody chooses to use one to attach something, I probably wouldn't 
object. Certainly when judging this from a black box perspective you 
can't know *why* the OPTIONS was sent. In the particular case of MSD, if 
it can either be sent with INFO as you propose, or with UPDATE, then I 
would probably recommend INFO.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Sep 2016 18:29:22 +0000

Hi,

...

>> I think is a separate question, not related to the INFO usage. But, to answer your question: in my opinion, if 
>> you are sending an UPDATE for whatever valid reason, I think it is ok to  include MSD as additional-data. But, I 
>> don't think one should send UPDATE just for the purpose of conveying MSD - for that one should use INFO.
>
> IIUC UPDATE may be used as a noop, good for testing the liveness of the path and the other end, better in some 
> respects than OPTIONS. If somebody chooses to use one to attach something, I probably wouldn't object. Certainly 
> when judging this from a black box perspective you can't know *why* the OPTIONS was sent. In the particular case 
> of MSD, if it can either be sent with INFO as you propose, or with UPDATE, then I would probably recommend INFO.

I would actually support MUST use INFO, unless you happen to send UPDATE for some other purpose. I don't want people to start using UPDATE instead of INFO, because that's not proper SIP, in my opinion. MSD is application information, and doesn't impact the SIP session state, so INFO shall be used.

If someone wants to forbid usage of UPDATE for transporting MSD in *any* circumstance, and only allow INFO mid-session, I probably would not object to that either :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 1 Sep 2016 14:52:49 -0400

> If someone wants to forbid usage of UPDATE for transporting MSD in *any* circumstance, and only allow INFO mid-session, I probably would not object to that either :)

I guess you can forbid this usage for MSD if you wish, as part of the 
definition of MSD.

I don't think you can forbid it for all uses of cid: in sip header fields.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Sep 2016 19:15:28 +0000

Hi,

...

>> I would actually support MUST use INFO, unless you happen to send UPDATE for some other 
>> purpose. I don't want people to start using UPDATE instead of INFO, because that's not proper 
>> SIP, in my opinion. MSD is application information, and doesn't impact the SIP session state, so INFO shall be used.
>>
>> If someone wants to forbid usage of UPDATE for transporting MSD in 
>> *any* circumstance, and only allow INFO mid-session, I probably would 
>> not object to that either :)
>
> I guess you can forbid this usage for MSD if you wish, as part of the definition of MSD.

...or, in draft-ecrit-ecall we can say that MSD can only be sent in the initial INVITE and INFOs.

Also, the rate of INFOs can be "controlled" within the info package specification, but there is nowhere to do it for UPDATE. So, the more I think about it, there more I think we should NOT allow MSD in UPDATE. I don't really see a need for it, as MSD is not expected to be sent too often to begin with.

An UPDATE can of course be used to re-negotiate the supported info packages, but that's a separate thing (which I don't think is needed for ecall).

Regards,

Christer

---

From: <[email-masked]>
Date: Thu, 1 Sep 2016 20:06:06 +0000

Hi Christer,

>...or, in draft-ecrit-ecall we can say that MSD can only be sent in the initial INVITE and INFOs.

That I would prefer, because I assume that we will have a lot of calls where we even do not need any additional MSD send in the midcall (i.e. INFO). 

So I would save an additional roundtrip in SIP to get the information.

Best regards

Roland

-----Ursprüngliche Nachricht-----
Von: sipcore [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Donnerstag, 1. September 2016 21:15
An: Paul Kyzivat; [email-masked]
Betreff: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal

Hi,

...

>> I would actually support MUST use INFO, unless you happen to send 
>> UPDATE for some other purpose. I don't want people to start using 
>> UPDATE instead of INFO, because that's not proper SIP, in my opinion. MSD is application information, and doesn't impact the SIP session state, so INFO shall be used.
>>

Regards,

Christer

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sat, 3 Sep 2016 12:48:45 +0000

We need to distinguish between the "application" and the data transfer mechanism. The ecall draft writes requirements for the "application", and that can state that additional data MUST ONLY be used in initial INVITE and its responses.

I do support the "application" only using the Info package for all its other data transfer requirements.

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 01 September 2016 20:15
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal

Hi,

...

Regards,

Christer

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sat, 3 Sep 2016 12:48:46 +0000

>From my perspective I don't think we can call this a compromise until we understand what the proposal requires in the error situations. So what happens at the recipient when:

-	a Call-Info is not included in the INFO request
-	an invalid Call-Info (i.e. pointing to some non-existent data element) is included in the INFO request
-	a Call-Info is included that point to data associated with some other usage, but none included for the ecrit data.

In my view in all these cases the Info package data has been validly transferred. Is this the understanding in the proposal?

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 01 September 2016 19:15
To: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal

On 9/1/16 12:32 PM, Christer Holmberg wrote:
> Hi,
>
>>>> Your example is incomplete (e.g., multipart is specified but only 
>>>> one body part is shown), and I hesitate to comment without first seeing exactly what you mean. Can >you please provide a complete example?
>>>
>> The prior approach was able to send the MSD on the response to the 
>> INFO that requested it, Or to send it attached to some message 
>> following that request. IIUC, in your approach here there will first be a response to the INFO request (no body) followed by another INFO in the other direction of the form you show here.
>

IIUC UPDATE may be used as a noop, good for testing the liveness of the path and the other end, better in some respects than OPTIONS. If somebody chooses to use one to attach something, I probably wouldn't object. Certainly when judging this from a black box perspective you can't know *why* the OPTIONS was sent. In the particular case of MSD, if it can either be sent with INFO as you propose, or with UPDATE, then I would probably recommend INFO.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 Sep 2016 15:06:34 +0000

Hi,

>From my perspective I don't think we can call this a compromise until we understand what the proposal requires in the error situations. So what happens at the recipient >when:
>

Yes. I guess I should have made that more clear.

In my proposal, we are using an Info Package to transfer the MSD, and the semantics etc are according to the info package specification. The Call-Info etc is there for "convenience", for those who want/need it.

So, when it comes to draft-ecall-11, the biggest change is to make sure that the text talks about "using the info package mechanism" instead of "using the Additional Data mechanism". The info package specification would then state that the Call-Info etc can be included for convenience, but that they don't overwrite the semantics etc associated with the info package.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 01 September 2016 19:15
To: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal

	Thanks,
	Paul