Subject: [sipcore] Review of draft-ietf-sip-info-events-03

From: Vijay Gurbani <[email-masked]>
Date: Sat, 06 Jun 2009 23:17:55 -0500

Sorry for the long review.

Summary statement:
This draft is on the right track but has open issues,
described in the review.

First of all, thanks for tackling this particular piece of work;
this is good stuff and it will make life easier for many
developers.

That said, the draft needs a substantial amount of work to be ready
for publication, both at the editorial level and at the content level.
Editorially, it is currently written in a collegial and informal
style, which is not appropriate for a standards-track document, and an
important one at that.  Besides gratuitous commas and run-on
sentences, the draft also contains phrases like "...and so on", "some
may think", "It is the hope of this draft's authors", "we could be
lazy ...", "we require...", "use a totally externally signaled
channel", "can do stuff", etc. (you get the idea.)  I think that
choosing one author as an editor and allowing him a couple of free
hours and a pint or two of beer will not be a bad idea ;-)

General comments (3 comments):
------------------------------
1) When talking about entities receiving or sending INFO requests, you
should either stick to "UAS" and "UAC" respectively, or "server" and
"client", respectively.  As the text is now written, in some places
"UAS" is used and in other, "server" is used.

2) Should we add a subsection in S7 on INFO refresh (see comment
number 10 in the next section for more context)?

3) I found the Appendix fairly useful as historical context.  Is the
idea to retain it going forward?  If so, you may want to edit it
carefully.  Right now it looks like it has been written by two
co-authors independently and then mashed together: note that SA.1 -
SA.4 contain pretty much the same information as SA5.

Substantive content-specific comments (24 comments)
---------------------------------------------------
1) S1, third paragraph, sentence on line 9: what you are describing
here is more akin to a problem of deciding how to render a JPEG image
instead of supporting it.  The sender and receiver both support the
JPEG image, where "support" means they will send and receive the
image; it is just that the receiver does not know how to render the
image because the sender did not provide any hints when it sent the
image.

I think you need to phrase the discussion here in that there is a
multiplicity of ways to render an image received with a "image/jpeg"
MIME type and that the sender of the image needs to provide some hints
to the receiver on how to render it.  In much the same way, the new
INFO package proposes to provide some hints to the receiver on how to
make sense of the user-to-user information being exchanged in the INFO
message.

2) S1, page 5, fourth paragraph, it is stated that "This document
provides a similar framework for INVITE-based application level
information exchange."  Do you not mean "INFO-based application level
information exchange instead?

Additional comment in the same paragraph: collect all the places where
you talk about SUBS/NOT in one place and distinguish them from how
Info packages are supposed to work.  Currently, you talk about
SUBS/NOT, then you talk about INFO, and then circle back to SUBS/NOT
and hop to INFO to close the paragraph.  This leaves the reader going
back and forth trying to bridge the gap between how SUBS/NOT differs
from INFO.  While this is okay for old SIP hands, new developers who
do not have the history of SIP embedded in their DNA genomes will be
completely lost.

3) S1, page 6, first complete paragraph on that page: I would suggest
that you replace "near end" and "far end" with something else; for
instance, instead of saying "If the far end indicates it can receive a
package offered by the near end,..." how about "If one peer indicates
it can receive a package offered by the the other peer ...".  The
terms "near end" and "far end" are subjective: near to who?  far from
who?

Same paragraph, you may also want to inform the reader that the
Recv-Info and Info-Package headers are both defined in this document.
That is, instead of saying "The Recv-Info header indicates ...", how
about "The Recv-Info header, defined in this document, indicates ...".
Similarly for the succeeding sentence that discusses Info-Package.

4) Section 3 requires a lot of work, IMHO; more so because this is a
very important section and lays down the behavior of the communicating
entities.  As such, as much as we can avoid ambiguity here and provide
clear instructions to developers, the better off we'd be in the long
run.  The next few issues are around making this section less ambiguous.

S3.1, general comment on the section: it appears that this section
has been written while keeping a UAS in mind.  It will be much better
if this section was broken down into two subsections, one discussing
UAS behavior and the other discussing UAC behavior.

5) S3.1, first paragraph: As I read this paragraph, is becomes obvious
that if we do not specify in some detail how the negotiation for
sending Recv-Info is done, we could run into interoperability
problems.  For instance, given the INVITE transaction, I can see at
least two ways to probe for support of this package:

  i) Initiating-UA triggered INFO package negotiation:

     INVITE sip:...
     Recv-Info: foo, bar
     ...

     180 Ringing sip:...
     Recv-Info: bar

or

  ii) Target-UA triggered INFO package negotiation:
      INVITE sip:...
      ...

      180 Ringing SIP/2.0
      Recv-Info: foo, bar
      ...

      ACK sip:...
      Recv-Info: bar

In case (i), the UAS could have indicated support for the INFO
packages in a 200 as well.  In case (i), the ACK will not have any
Recv-Info headers (please confirm.)

Now, to make matters more complex, from the table in S5.2, it appears
that INFO negotiations can be done in a PRACK/200 and an UPDATE/200 as
well.  While doing the INFO negotiation in UPDATE/200 is fine, I am
curious why we would want to do it in PRACK/200, since that particular
transaction is nested within the INVITE transaction (thus adding more
complexity when it could easily be avoided.) Is that the intent?  Are
we sure we want to add this additional complexity on top of PRACK?  Is
there a good reason why we would want to take on additional complexity
introduced by PRACK.  If there is, we should at least provide clear
guidelines.

So, there are two specific comments here: (1) Provide better
guidelines to implementers (see case i and ii above) including showing
portions of a SIP message and flow to be more explicit on the intent;
and (2) determine if we need to do INFO event negotiation in a PRACK,
and if so, provide better guidelines, including showing call flows and
portions of SIP messages to be more explicit of the intent.

6) S3.1, page 7, last paragraph, second last line:
s/the UAS MUST list the preferred Info Package lexically earlier in
the message./it MUST maintain an ordinal sequence of the preferred Info
Package among others./

7) S3.1, page 8, towards the top of the page it is said that "Listing
a package multiple times does no harm."  I am curious, why even allow
the listing of the same package multiple times?  It will make parsing
more cumbersome and force the receiving side to maintain a larger set
of Info packages where some elements may occur multiple times.  All
this can be trivially avoided by just mandating that packages must be
listed once.

8) S3.1, the indented "NOTE" in the middle of page 8: I would advise
to make the text more terse and more formal; something like the
following (please feel free to edit as you see fit):

   NOTE: While an empty Recv-Info header could be used to indicate
   that the sender does not wish to receive any Info packages, such
   usage will fall short should a richer negotiation strategy be
   required at some later time.  Using the value 'nil' makes the
   intent of the sender of the Recv-Info request explicit.

9) S3.1, page 8, in the discussion on the second half of that page, I
am lost as to your intent.  The initiating UA sends an INV with
support for two packages P and R.  You do not show what the target UA
supports -- did it support both packages, or did the target UA send a
200 OK with an additional package, T?  You then go on to show an ACK
going from the initiating UA with package R and T.  This implies that
there is an offer/counter-offer/answer type of negotiation, which is
not what you had outlined in the beginning of Section 3.1.  Can the
target UA add a package that was not present in the Recv-Info header
of the initiating UA?  This is very important to clarify if we want to
get the negotiation right.

10) S3.1, page 9, the paragraph "In the case of ... specified by this
document." is a very important one and needs to be highlighted more.
Essentially, if I read the paragraph correctly, the validity of an
INFO message is bounded by either of the following two conditions:
   (i) The dialog is terminated normally; or
   (ii) A peer receives a dialog refresh request, but that request
      did not have a Recv-Info header in it.

Case (i) can be characterized as the normal behavior, after all, if a
dialog goes away, it makes sense that any state associated with it
vanishes as well.  Case (ii), however, is rather important if the
intent of the draft is indeed to terminate Info package state if it is
not refreshed by a dialog refresh request.

Case (ii) implies that Info packages have a lifetime that may be less
than that of the dialog in which they are contained.  If that is
indeed the case, then a mid-dialog refresh request appears to be a
means to terminate an Info package state before the dialog itself is
terminated.  This would normally be okay, but brings to the fore
another important question: what if a dialog usage does not have a
mid-dialog request but the services of an Info package are no longer
needed for the duration of the lifetime of the dialog.  In such
a case, should we come up with a specific Info-Expires header?

To make matters worse, while S3.1 appears to state that the Info
packages may have a lifetime less than that of the dialog they are
contained in, S4.1, fourth paragraph, appears to contradict this
assertion.  In S4.1, fourth paragraph, it is stated that "The INFO
method has no lifetime or usage of its own ..."

So, some more thoughts on the lifetime of an Info package seem
appropriate and they should be spelled out in detail in this section.
Personally, I think that it should be okay to simply bound the
lifetime of an Info package with that of the dialog and leave it at
that.  Exhorting implementers to expire an Info package if the dialog
refresh did not include a Recv-Info header seems to be calling for
more complexity than needed.  Are there existing usages of Info that
require such behavior?

11) S3.2, second paragraph: The second reason for why versioning is
not supported needs to be made a bit more clear.  I would suggest the
following replacement text (edit as needed):

   A second reason for not supporting a package versioning system
   is that not all payloads are capable of encoding a version
   number.  In the end, while it is easy for user agents to
   negotiate Info package support, asking them to also negotiate
   specific package versions closely ties the signaling to a
   specific payload version.  Since the payload is to be
   interpreted by a transaction user, such coupling may not be
   beneficial as a general rule.

12) S4.1, page 10, last paragraph: I am curious -- why are we allowing
early INFO requests?  More so since when they interact with
forking, they seem to produce undesirable complexity.

RFC2976 does not mention INFO forking in the context of a initiating
UA receiving multiple INFO messages, which is what is being discussed
here.  RFC2976 does talk about the INFO request forking, but this is
in the context of a forking proxy sending out multiple INFO requests.
As such, if we intend to allow the first behavior, i.e., an initiating
UA receiving multiple INFO requests as result of a forked INVITE, then
we'd better say a lot more than this one paragraph on the resulting
complexity (this small paragraph is the only place in the document
where early INFO is mentioned.)  The behavior in this section for such
a case is inadequately specified: should the initiating UA expect INFO
requests before the provisionals or after the provisionals, or does it
not matter?  What if PRACK is used?  Should the target UA wait for a
PRACK before it sends an INFO?  And so on.

IMHO, since we are defining new behavior for INFO, why take on
additional complexity in the form of burdening the initiating UA with
receiving multiple INFO requests?  Is there a proposed Info package
that requires such behavior?  Or conversely, is there a legacy Info
usage whose behavior we want to preserve by this complexity?  If the
answer is no, then I really think we should simply mandate that the
INFO request is to be sent once the dialog has been established.

13) S4.2, second paragraph: I don't understand this -- why is it left
to the UAC to determine whether it is "appropriate to send that
payload to the UAS"?  Should this not be the task of the Info package
designer?  In other words, all we need to say here is "If the Info
package defines a payload, the UAC MUST include the payload and the
MIME type described in the Info package."

14) S4.2, third paragraph: The sentence here is self-evident; I am not
sure why list this behavior out explicitly.

15) S4.2, fourth paragraph: what do you mean by "INFO proper"?  I
presume you either mean RFC2976, or the ad-hoc use of INFO in the
Internet.  If so, please restate as such.  If not, please amplify the
meaning of "INFO proper".

16) S4.7, first paragraph, it is stated that the "UAS cannot use the
CSeq to determine the sequence of INFO messages."  I am not sure I
understand why.  Is it not the case that the CSeq number of later
requests will be higher than the one of previous requests?  Sure,
there will be gaps, but later requests will have a CSeq number bigger
than previous ones.

Same section, second paragraph, it is stated that "Since overlapping
requests will occur even if the application (Info package) does not
allow it..." -- I don't understand why overlapping would occur if
the Info package did not allow it?  Is it because of some legacy INFO
usage that behaves in this way?  If so, simply state that as the
reason, and if not, you may want to add text that supports why a
developer should be prepared to handle overlapped requests if the Info
package prohibits these.

17) S6, last paragraph: should we not do more than "hope" that vendors
who implement proprietary Info usages submit their mechanisms as Info
package extension documents?  That is, shouldn't we "require" them to
do ss at least using a SHOULD strength?

18) S7.1 - S7.11: In certain sub-sections, the text says "This
section, [...], MUST be present..."  Why the singling out of certain
sections in this manner?  Shouldn't it be the case that ALL sections
MUST be present in an Info package extension document?  If they are
not relevant to that specific package, the package designer can simply
state "N/A".  As these sections are now written, if I was an Info
package designer, I would automatically assume that some sections,
especially those ones where it does not say that they MUST be present,
can be omitted when documenting my Info package.

I don't think that is the intent here, is it?

19) S7.6 and S7.7: I think the meat of these two sub-sections deals with
overlapped INFO requests, and as such, a new sub-section on this topic
should be added if overlapped requests are to be allowed.  The UAC
generation of INFO requests takes only a paragraph and can be moved to
its own sub-section.  Likewise for UAS processing of INFO requests.

20) S7.10, discussion in the middle of the section: The reason for not
mandating TLS is not because there are "few protocol mechanisms to
enforce this" -- indeed, there are few protocol mechanisms to enforce
any arbitrary behavior, which is why policing network traffic is so
lucrative a business model.  The main reason why TLS is not sufficient
is because of its hop-by-hop nature, intermediaries will be privy to
any INFO package contents.  Now, there really isn't a way around this
in SIP unless you do an end-to-end certificate exchange to bootstrap
TLS.  S/MIME, which is given as an option in the draft, is academic
since I do not believe that many SIP implementations, if any, support
it at all.

I am not sure what to say here except that the text needs to be
cleaned up a bit to inform Info package designers that while TLS is
better than nothing, it will still leak Info package bodies to
intermediaries (i.e., remove the "few protocol mechanisms to enforce
this" sentence.)  Those Info implementations that want to protect
their payload should use S/MIME or some other means to prevent
intermediary eavesdropping.

21) S8, in the Info-package-type production rule, why is the dot (".")
used to separate parameters when everywhere else in SIP the
semi-colon (";") plays the same role?

22) S10: S7.11 asks Info package designers to provide
complete and syntactically correct SIP messages as examples.
Ironically, this very issue is violated by your examples :-)
It would be good to provide complete messages, if possible.

23) S10.1: The example in this section can also result in a situation
where package "bar" never gets triggered even though Bob may indeed
support it.  Here's how, and please let me know if I am
misunderstanding something here: Let's say Bob supported both "foo"
and "bar".  According to your text in S10.1, while Alice supports
sending "bar", she can send AND receive "foo"; so she only puts "foo"
in the Recv-Info header.

Now, when the Recv-Info header reaches Bob, all Bob knows is that
Alice supports receiving "foo".  Bob can receive "bar", but does not
know that Alice can indeed send "bar".  So, "bar" as an Info package
has inadvertently been cut out.  This is not good, right (if I am
missing something critical here, please do let me know.)

If the above is indeed true, then we may have a bigger problem on our
hands. The example in this section got me thinking about the
distinction between Recv-Info containing package names that can be
sent and received versus packages that can only be sent (and
therefore, not received?)  The text in S10.1 states that "Alice can
support sending or receiving "foo" Info packages, and sending "bar"
Info Packages."  Does that mean that Alice cannot receive "bar"
package?  Only send it?

Is there a distinction between Recv-Info containing package names that
a UAC can "send", "receive" or "send and receive"?  S1 starts to tease
this on page 6 when it states that "Each UA enumerates which Info
Packages it can receive." but it does not finish the discussion; much
is left unsaid.  Does that mean that when a UAC includes an Info
package name in Recv-Info, it can only receive that type of package
but cannot send it?  In fact, how can a UAC indicate support for Info
packages that it can send?  It looks like a UAC cannot use the
"Supported" header for this (c.f., S3.1).  Similarly, how does a UAC
include support for Info packages it can send and receive?

Clearly, if a UAC is capable of receiving an Info package, is it not
capable of sending it as well?  In other words, consider the following
exchange -- a UAC sends:

   INVITE ...
   Recv-Info: A, B

to which a UAS replies:

   200 OK ...
   Recv-Info: B

And the UAC now sends an INFO request with Info package B.  So,
"receive" seems to automatically imply "send", and thereby "send and
receive" as well.  Am I correct or am I just plain missing something
here?  To me at least, this is a rather important distinction that
ought to be spelled out.  Right now I am not sure whether Recv-Info
implies both receive and send -- I think it does, but portions of the
draft lead me to believe otherwise.

24) S11: I think what you are trying to do here is to establish a Info
package registry in the same way that we established the tel URI
parameter registry (RFC5341) and the sip URI parameter registry
(RFC3969), correct?  If so, I agree with the note that this section
may be a separate document altogether since the mechanics of assigning
an expert review, etc. are described in such registry documents (you
can use RFC5341 and RFC3969 as templates.)

Nits and editorials (11 comments)
---------------------------------

1) Abstract, first sentence: Instead of saying, "This document
defines a new SIP INFO method", probably better to say that
"This document provides new semantics to the INFO method of
RFC2976, obsoleting the old usage in a backwards-compatible
manner."

My reason for this comment is that this document is not defining
a new method called INFO as much as it is trying to provide a
new context and semantics for the use of an existing method called
INFO.

2) Abstract, paragraph three:
s/Be mindful/The reader is urged to be mindful/

3) S1, page 6, last paragraph:
s/Conversely, this can be/Conversely, this can also be/

4) S3, opening paragraph:
s/To be abundantly clear, as stated/As stated

5) S3.1, page 8, towards the end of the page:
s/send form package/send package/

6) S3.1, page 9:
s/UA in the dial will/UA in the dialog will/

7) S3.1, last paragraph: consider replacing "far-end" with something
else -- something as such:

OLD
If the far-end UA does not indicate support for an Info package that
the local server requires, the server MAY terminate the session with
a CANCEL or BYE request.

NEW
If the UA receiving the INFO request did not indicate support
for a required Info package, the sender of the INFO MAY
terminate the session with a CANCEL or a BYE request.

8) S4.3, page 13, the indented "NOTE" paragraph at the top of the
page: I think you can remove this paragraph -- you are mandating that
a 489 be sent when the UAS receives an INFO message with a package it
does not understand.  That should be it; I think pointing out the link
between INFO and NOTIFY serves only to confuse the issue.  As a
developer, I want to know what to send when I get a request I cannot
handle.  As long as the good RFC tells me to send a 489, so be it.

9) S4.3, page 13, second paragraph:
s/but it has no/but the INFO request has no/
s/as it sees fit//       (i.e., remove "as it sees fit")

10) S8, first paragraph:
s/user-to-user data exchange in SIP./INFO method./

Same section, second paragraph is redundant and can be easily removed
without impacting readability or understanding.

11) S12, first paragraph:
s/improve the security of the Internet./improve the security of
SIP-based communications./

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://ect.bell-labs.com/who/vkg

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Jun 2009 23:31:18 -0400

Vijay,

Wow! A very thorough review!!! I haven't had time to do so.
I just provide a few observations inline on yours.

	Thanks,
	Paul

> General comments (3 comments):

There is need to get the negotiation done well before the ACK, so that 
the INVO can be used before the request is accepted. (At least I think 
it is.)

That is covered in case (1), but if it is UAS that wants to use it, then 
case (2) isn't enough. This could be covered using 18x/prack. Or it 
could be covered using UPDATE.

> a case, should we come up with a specific Info-Expires header?

This termination mid-dialog is important to ensure that 3pcc scenarios 
can work.

I don't understand your question here. If you want an info usage to go 
away mid-dialog, why not use a dialog refresh to cause that? This would 
be entirely analogous to termination of a session-timer mid-session.

> more complexity than needed.  Are there existing usages of Info that

Any time you do a 3pcc transfer, one side things their dialog is 
preserved, while on the other side there have been two distinct dialogs. 
If the first of those supported the info pkg, but the 2nd does not, then 
you need a way to renegotiate.

> forking, they seem to produce undesirable complexity.

Well, since the poster child has always been DTMF, that is something 
that is frequently desired in early dialogs.

> INFO request is to be sent once the dialog has been established.

Once again I think DTMF gives an example.
You might need to send it during early dialog, and in conjunction with 
forking you then may be exchanging them on multiple early dialogs.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 08 Jun 2009 10:41:32 -0500

> I just provide a few observations inline on yours. 

Paul: Thanks; more inline.

> could be covered using UPDATE.

OK, so then the negotiation aspects can be sub-sectioned off
to show how a UAC would negotiate and use INFO packages and
how the dynamics for triggering this negotiation by the UAS are
different (essentially, take the two cases I outlined in my
email and make them into sub-sections.)

Of the two cases, case (ii), the Target-UA triggered INFO
package negotiation (i.e., UAS-triggered) is the more complex
case.  As you say, it can be covered using 18x/PRACK or
UPDATE.  I suspect that the draft will have to provide guidance
and examples on how to use both UPDATE and 18x/PRACK (I am
sorry I am not being obstinate here, but if the draft does
not provide guidance on which one to use and how, history shows
that with more choices for doing a piece of work comes
the inevitable question of interoperability.)

I will leave it to the authors to determine whether or not one
is a preferred mode of negotiation, though it seems to me that
there should be some guidance provided to implementers (it may
be as simple as saying that if the UAC did not have "100rel" in
a Supported header, then the UAS MUST use UPDATE to trigger a
INFO negotiation.  If the UAC supports "100rel", the UAS MAY
use PRACK or UPDATE.)

> be entirely analogous to termination of a session-timer mid-session.

I was more worried about the case that suppose an INFO message
installs some (non-dialog) state in the recipient.  As the
dialog progresses along, the state becomes stale and is no longer
needed.  But, there is no mid-dialog communications between
the peers, which would normally cause the stale state to be
flushed.  As such, the recipient will have to maintain the
now stale state until the dialog is torn down.

Now granted that this type of scenario may not apply to
existing INFO usages, but since the draft takes the burden
of discussing how to refresh Info packages, it implies
that there is a lifetime to these packages.  Ergo, it should
also cover the case where such refreshes are not done
(I realize I am being a pedantic protocol designer here,
so I will shut up if the WG feels that this is a moot point.
An easy way to handle this would be to state simply that if
no mid-dialog requests arrive to refresh the Info package
state, then the state is simply maintained until the normal
termination of the dialog.)

> you need a way to renegotiate.

I am not sure I follow, can you please elucidate...

> that is frequently desired in early dialogs.

Ah, enough said ;-) I think it will do some good in the draft
if the reason for an early INFO message (namely, DTMF) is
mentioned there (suggested text below.)

> forking you then may be exchanging them on multiple early dialogs.

Hmmm ... okay; I can buy that.  It will be good to just put
down some text that gives the reason for supporting multiple
INFO requests as a side-effect of forking.  Something along
these lines:

OLD:

    The converse is not true during initial session establishment.  The
    initiating UA of the first INVITE MUST be prepared to receive
    multiple INFO requests, as the first INVITE may fork.  Since dialog
    negotiation has not completed, and we allow early INFO requests,
    multiple target UAs may respond.  This initial dialog establishment
    phase is the only time the UAS need be prepared to receive multiple
    INFO requests, as we require post-session-establishment negotiation
    to fully complete before a UAC can send an INFO request.

NEW:

    The converse is not true during initial session establishment.  The
    initiating UA of the first INVITE MUST be prepared to receive
    multiple INFO requests, as the first INVITE may fork.  Since dialog
    negotiation has not completed, and we allow early INFO requests,
    multiple target UAs may respond.

       When an INVITE forks and reaches multiple targets, these
       targets may want to interact with the initiator of the
       INVITE for some services, DTMF being the canonical one.
       The complexity of early INFO requests is thus needed
       to handle such interactions.

    The initial dialog establishment phase is the only time
    the UAC need be prepared to receive multiple INFO requests,
    as we require post-session-establishment negotiation to
    fully complete before a UAC can send an INFO request.

(Note that there was a typo -- I think -- above.  In the original
text, it says "This initial dialog establishment phase is
the only time the UAS need be prepared to receive multiple INFO
requests...", but I think the authors meant the *UAC* should be
prepared to receive multiple INFO requests.  I have corrected
this in the modified text.)

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jun 2009 12:42:11 -0400

Vijay K. Gurbani wrote:
>> That is covered in case (1), but if it is UAS that wants to use it, 
>> then case (2) isn't enough. This could be covered using 18x/prack. Or 
>> it could be covered using UPDATE.
> 

I'm fine with all you say above. I agree that spelling things out 
clearly is important given the difficulties we have had in the past when 
not doing so.

>> away mid-dialog, why not use a dialog refresh to cause that? This 
>> would be entirely analogous to termination of a session-timer 
>> mid-session.
> 

Perhaps the term "refresh" should not be applied to info packages.
Perhaps a different term, such as "revise" would be better.

I've harped for a long time that the lifetime is poorly defined for many 
of the things we negotiate. Here we have the opportunity to be clear.

Having said that, and in light of your comments, I think we may be 
talking about two things:

1) the state that consists of the info packages that have been
    negotiated to be usable on the current dialog.

2) the state of *something* that is negotiated by the exchange of
    some particular info messages.

For (1), IMO the negotiated state should remain in effect for the dialog 
until and unless changed by some additional signaling exchange. In 
particular, I think each reINVITE or UPDATE has the opportunity to 
change this, and should probably start out with a clean slate, except 
that the last agreement remains in effect until the new one is fully 
negotiated. This can however be tricky to nail down. (Witness all the 
issues around rollback of O/A. Lets not repeat that fiasco.)

For (2), I think that the rules must be be defined when some new 
negotiation is specified to use INFO as its transport. I don't see 
anything we should necessarily define as part of the general info 
package mechanism. There is an interesting case that might be worth 
discussing:

Suppose Info package P is negotiated. Then exchanging messages of type 
P, some state is agreed upon between UAC and UAS. And assume that it is 
intended to remain in effect within the dialog until changed by another 
exchange of messages of type P. Then suppose that a reINVITE or UPDATE 
removes the agreement to use Info package P. Does the agreement 
previously established remain in effect even though there is no longer 
any way to revoke it?

I guess my thought on that is that it is up to the designers of package 
P to specify what happens in this case. But they had better be careful 
about it.

>> preserved, while on the other side there have been two distinct 
>> dialogs. If the first of those supported the info pkg, but the 2nd 
>> does not, then you need a way to renegotiate.
> 

OK. Lets take the usual 3pcc use case:

              |-------- C
              |
   A -------- B
              |
              |-------- D

Here A, C, and D are UAs, and B is a B2BUA.
Initially A sends an INVITE which is received by B, who sends a 
corresponding INVITE to C. The AB and BC dialogs are coordinated by B so 
that it seems that A has a session with C.

During that setup, A includes Recv-Info:P, as does C in its response. A 
and C the proceed to exchange Info packages of type P.

At some point, B decides that the "call" should be transferred to D. 
This can be for a lot of reasons. In order to preserve consistency, B 
sends an offerless invite to A. And I think it is probably also 
Recv-Info-less. Lets assume for now that A immediately sends a 200 
response, with offer, and with Recv-Info including P.

B then uses that to send an INVITE to D. But D does not support info 
package P, so it doesn't include that in its Recv-Info.

We need to end up in a situation where A knows that info package P 
cannot be used.

> INFO requests as a side-effect of forking.  Something along

I agree with your points above.

>    fully complete before a UAC can send an INFO request.

The above isn't working for me.

What I think is lacking, and something that seems confusing to people on 
a regular basis, is clarity on the point that the multiplicity is due to 
multiple dialogs. As long as you consider things from the point of view 
of an individual dialog, there is nothing special here. Also, I don't 
think the paragraph is the converse of anything stated previously. So, 
how about:

NEW:

    While INFO cannot fork, an initial INVITE may fork, resulting in
    multiple early and/or full dialogs. A UA must be prepared to receive
    INFO requests over each dialog resulting from an INVITE it has sent.

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 08 Jun 2009 12:09:18 -0500

> of the things we negotiate. Here we have the opportunity to be clear.

Agreed; I think that the authors of the draft should spend
some time thinking through the issue of Info package lifetime
and impacts on refreshing/revising it.  The discussion captured
in this email thread can help frame the text in the draft,
especially the different states that can be instantiated in

>    some particular info messages.

Complicating the issue of lifetimes is the 3pcc case you
describe below (your comment makes sense to me now, with an
example you provided.)  Obviously, the motivation of expiring
an Info package if the dialog refresh did not include a Recv-Info
header makes sense in the context of the 3pcc example you
gave.  Without that context, it did not make sense.

The authors, from an editorial point of view, may want
to justify the reason why Info packages expire if the
dialog refresh reveals that one side does not support
Recv-Info.  I realize that they cannot simply give examples
each time they describe behavior, but when describing a
rather complex behavior that an implementation must support,
it may be well worth to buttress the behavior with an
example.

[...]
> OK. Lets take the usual 3pcc use case:
[...]

OK; I see your point.

> [...]So, how about:

This works for me.

Thanks,

- vijay