Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11

From: [email-masked] (Dale R. Worley)
Date: Thu, 01 Sep 2016 10:46:52 -0400

Christer Holmberg <[email-masked]> writes:
> In general, if intermediaries are going to add content to INFO, and if
> such information can only be added to specific INFO usages, the
> intermediaries will have to look at the Info-Package header field (and
> in some cases perhaps also look at the content) in order to figure out
> what the INFO is all about.

Yes, that must be the rule.  But I don't see the particular rule stated
in draft-ietf-ecrit-ecall-11, even though that draft introduces the
mechanism for updating MSD, and thus updating Additional Data.

RFC 7852 is also rather vague regarding which requests should have
updated Additional Data added.  Section 6.1 is generic:

   A URI to a block MAY be inserted in any SIP request or response
   method (most often INVITE or MESSAGE), using a Call-Info header field
   containing a 'purpose' value starting with 'EmergencyCallData', a dot
   ('.'), and the type of data available at the URI.

but the examples seem to presuppose that it will only be done in INVITE
requests.  That processing seems to be expected to be bundled with all
of the emergency-call-specific processing carriers already do for those
INVITEs.

> People want to use the Call-Info header field in INFO because it is
> used in INVITE (and possibly other methods), but technically you don't
> need it in order to get things to work if you are using an info
> package.

That's true.  The only reason is to be consistent with how INVITEs are
processed.

Dale

---

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

> Yes, that must be the rule.  But I don't see the particular rule stated in draft-ietf-ecrit-ecall-11, even though that draft introduces 
> the mechanism for updating MSD, and thus updating Additional Data.

There are no ecall requirements for intermediaries to insert any information.

And, the MSD is sent from the endpoint, not from any intermediary.

...

> That's true.  The only reason is to be consistent with how INVITEs are processed.

Yes. 

But, I have proposed a compromise, where we would use an info package, but still be able to insert Call-Info in the INFO request.

Regards,

Christer