Subject: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Nov 2007 23:08:17 -0500

Howdy,
Just an FYI that Christer and I submitted a draft for SIP INFO events, based on the email discussion.  This is on the agenda for Vancouver.
Cheers,
-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 08, 2007 11:00 PM
> To: [email-masked]
> Subject: I-D Action:draft-kaplan-sip-info-events-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>         Title           : SIP INFO Event Framework
>         Author(s)       : H. Kaplan, et al.
>         Filename        : draft-kaplan-sip-info-events-00.txt
>         Pages           : 12
>         Date            : 2007-11-08
>
> This document defines a proposed solution for defining, negotiating
> and exchanging info-event notifications in INFO messages, within SIP
> invite-created dialogs, for applications which need to exchange
> session-related information inside the invite-created dialog.  This
> draft addresses issues and open items from RFC 2976, and updates it.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-events-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
>         "get draft-kaplan-sip-info-events-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-kaplan-sip-info-events-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Nov 2007 14:57:11 -0600

In general, I think the mechanism outlined in 
draft-kaplan-sip-info-events-00 is a good starting place for 
disambiguating multiple usages of INFO, and I'd like to thank Hadriel 
and Christer for putting forth the effort to submit a concrete proposal. 
I have a number of specific suggestions for improving the mechanism that 
I'd like to offer up at some point in the future.

However, I can't support the document in its current form.

The current document conflates INFO packages with Event packages in a 
way that is quite dangerous -- even going so far as to call INFO 
packages "Event packages" in a few places (c.f. section 4: "The general 
concept is that the UAC generating an INVITE request includes the Event 
packages it supports sending and receiving, in two new headers: 
Send-Event and Recv-Event."). It confusingly re-uses the "Event" header 
field from RFC 3265, and even suggests that common packages can be 
defined for RFC 3265 and for INFO.

This harmful conflation between RFC 3265 event packages and INFO 
packages pervades the document. Until this issue becomes less confused 
in the text, I strongly believe that the document will do far, far more 
damage than good.

/a

Hadriel Kaplan wrote:
> ------------------------------------------------------------------------
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Nov 2007 16:07:16 -0500

Yeah my bad for not re-writing that whole thing.  It started out as a "rfc3265 Event Packages for INFO" type thing, but after your emails on the subject we were convinced that was a bad way to go.  I apologize for not cleaning it up better before submission.  Do you want me to re-submit using better terminology?  (unfortunately due to the submission deadlines I don't think I can do so officially?)

I was thinking this was really just a discussion point doc for the Vancouver meeting, and if the concept in general was adopted we'd fix all the terminology.

Sorry 'bout that.  :(

-hadriel

> From: Adam Roach [mailto:[email-masked]]
> Sent: Monday, November 19, 2007 3:57 PM
> To: Hadriel Kaplan
> Cc: [email-masked]; Christer Holmberg
> Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
>
> > Just an FYI that Christer and I submitted a draft for SIP INFO events,
> based on the email discussion.  This is on the agenda for Vancouver.
> > Cheers,
> > -hadriel
> >
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Nov 2007 12:31:02 +0100

Hi,

We shall note Adam's comment (Thanks for reading the draft, btw! :), but
I am not sure we need to re-submit before Vancouver. As Hadriel said, I
think we shall first discuss the concept, and then we can fix the
wording.

Regards,

Christer

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 19. marraskuuta 2007 23:07
> To: Adam Roach
> Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt
> 
> Yeah my bad for not re-writing that whole thing.  It started 
> out as a "rfc3265 Event Packages for INFO" type thing, but 
> after your emails on the subject we were convinced that was a 
> bad way to go.  I apologize for not cleaning it up better 
> before submission.  Do you want me to re-submit using better 
> terminology?  (unfortunately due to the submission deadlines 
> I don't think I can do so officially?)
> 
> I was thinking this was really just a discussion point doc 
> for the Vancouver meeting, and if the concept in general was 
> adopted we'd fix all the terminology.
> 
> Sorry 'bout that.  :(
> 
> -hadriel
> 
> 
> > Subject: Re: [Sip] FW: I-D 
> Action:draft-kaplan-sip-info-events-00.txt
> >
> > I have a number of specific suggestions for improving the mechanism 
> > that I'd like to offer up at some point in the future.
> >
> > packages "Event packages" in a few places (c.f. section 4: "The 
> > general concept is that the UAC generating an INVITE 
> request includes 
> > the Event packages it supports sending and receiving, in 
> two new headers:
> > Send-Event and Recv-Event."). It confusingly re-uses the "Event" 
> > header field from RFC 3265, and even suggests that common 
> packages can 
> > be defined for RFC 3265 and for INFO.
> >
> > in the text, I strongly believe that the document will do far, far 
> > more damage than good.
> >
> > /a
> >
> > Hadriel Kaplan wrote:
> > > Howdy,
> > >> and exchanging info-event notifications in INFO messages, within 
> > >> SIP invite-created dialogs, for applications which need 
> to exchange 
> > >> To remove yourself from the I-D Announcement list, send 
> a message 
> > >> to [email-masked] with the word 
> unsubscribe in the 
> > >> body of the message.
> > >> You can also visit 
> > >> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > >> http://www.ietf.org/shadow.html or 
> > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >>
> > >>         "FILE 
> /internet-drafts/draft-kaplan-sip-info-events-00.txt".
> > >>
> > >>         a MIME-compliant mail reader.  Different MIME-compliant 
> > >> mail readers
> > >>         up into multiple messages), so check your local 
> > >> documentation
> > on
> > > This list is for NEW development of the core SIP Protocol Use 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments on the application of sip
> 
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Nov 2007 16:06:39 -0600

> I was thinking this was really just a discussion point doc for the Vancouver meeting, and if the concept in general was adopted we'd fix all the terminology.

No problem -- I know how hectic things can get before the face-to-face 
meetings. Perhaps a bit more heads-up (either in the document or on the 
mailing list) that the event-package terminology was a known issue would 
have helped.

Comments follow. To prevent my fingers from burning while I type this, I 
will use the terms "Info Package", "Send-Info" and "Recv-Info" instead 
of "Info Event Package," "Send-Event," and "Recv-Event" as currently 
found in the document. I'll also talk about the header field 
"Info-Profile" instead of "Event".

----

General nit: s/header/header field/g

----

      [NOTE: do we need to support the "id" concept as well?  Is there 
   a use case?] 

The "id" concept in 3261 is to support multiple SUBSCRIBE usages in a 
dialog. Because INFO is part of an INVITE dialog, there can be only one. 
You don't need "id" for INFO.

----

The document needs some discussion around grandfathering existing 
standardized usages, similar to what 3265 did for PINT. Specifically, we 
want a way at the beginning of the dialog that one can use to usually 
detect that ISUP or QSIG will be sent, and text specifically indicating 
that ISUP and QSIG payloads without an "Info-Profile" header field can 
be interpreted according to the appropriate legacy RFCs. This impacts 
normative languages elsewhere (like the "MUST NOT" in the first 
paragraph of section 5.1).

I would be careful about grandfathering DTMF, simply because doing so 
would require clear definition of what those INFO messages mean, and 
consensus on that topic would take more than a little work. (A taste of 
what you'll argue about: do they represent tones? Keypresses? Generic 
user stimulus? Are they sent with in-band DTMF or instead of it? If you 
receive both, what does it mean? If they are tones, how do they get 
synced with the RTP stream and re-insterted?)

----

In terms of where the events are negotiated: I think this probably needs 
to follow the general offer/answer rules for greatest flexibility. The 
key reason is 3PCC. If a 3PCC is bringing two parties together to 
communicate, it won't be able to indicate supported Info Packages in the 
initial INVITE. It would be useful, then, for the first party contacted 
to be able to indicate Send-Info and Recv-Info in its 200-class 
response, and get a negotiated set of packages in the ACK.

----

   A Re-INVITE or UPDATE request MUST NOT contain any Send-Event or 
   Recv-Event headers, and such headers MUST be ignored on reception.  
   The info-event package negotiation is performed during the initial 
   INVITE transaction, and there is no re-negotiation. 
    
   [Is that ok?  Is there a need to have re-negotiation? (is there a 
   use case?)  It sure makes it simple not to have things change in the 
   middle of a session] 

I think you run into unsolvable 3PCC interactions here as well, since a 
3PCC can switch out one party of a call -- this could result in a 
completely different set of Info Packages being valid after the switch-out.

It is also remotely conceivable that a reconfiguration of the client may 
result in a change in available packages; for example, a client may 
advertise a video-related Info Package for video calls, but not for 
other kinds of calls; an upgrade to video under such circumstances would 
warrant a change in available packages.

----

   If an Invite usage fails or is terminated, the Info-based 
   event state no longer exists, and an INFO request MUST NOT be sent. 

You probably also want to briefly mention INFO/BYE glare (and similar 
situations) and how it should be handled.

----

   Recv-Event          18x        -   -   -   o   o   -   - 

I think you mean "1xx", not "18x"

----

The document needs to talk about appropriate rates of INFO transmission 
so as to not overwhelm the proxy network. You also need to discuss the 
responsibilities of Info Package definitions (similar to RFC 3265, 
section 4.4 and its subsections).

----

I would also suggest a discussion of Supported/Require as it pertains to 
specific Info Packages, so as to avoid the discussion around, "but what 
if I *want* the call to fail if a specific package isn't supported?"

----

Discussion of handling of the Send-Info and Recv-Info in REGISTER and 
OPTIONS is also warranted. You may think it's intuitive and doesn't need 
explanation, but I promise that people will get it wrong without 
specific language around what these things mean (for example: does the 
Recv-Info header field in an OPTIONS response describe all the Info 
Packages a UA can receive, or only that subset that was indicated in the 
OPTIONS request?).  I _DO_ think the presence of these fields in at 
least OPTIONS (and, to a lesser degree, REGISTER) would be a very useful 
thing.

----

Finally, I would argue that INFO is old enough (it predates 3261!) -- 
and consequently sufficiently out of date -- that it makes more sense to 
incorporate the definition of INFO into this document and aim to 
*replace* RFC 2976 instead of update it. (When you take the tables and 
boilerplate out of 2976, it comes to only a couple pages in length).

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Nov 2007 18:06:21 -0500

I agree with Adam's comments. I've added a small amount of commentary.

	Thanks,
	Paul

Adam Roach wrote:
>> Yeah my bad for not re-writing that whole thing.  It started out as a 
>> "rfc3265 Event Packages for INFO" type thing, but after your emails on 
>> the subject we were convinced that was a bad way to go.  I apologize 
>> for not cleaning it up better before submission.  Do you want me to 
>> re-submit using better terminology?  (unfortunately due to the 
>> submission deadlines I don't think I can do so officially?)
>>
>> I was thinking this was really just a discussion point doc for the 
>> Vancouver meeting, and if the concept in general was adopted we'd fix 
>> all the terminology.
>>
>> Sorry 'bout that.  :(
>>   
> 

I think the id is used to support multiple subscribe usages *of the same 
event type* in a dialog. (Not needed for different event types.)

Presumably more than one of these "Info Packages" can be used in the 
same INVITE dialog. I guess the question remains whether it would ever 
make sense to have more than one of the same type. I guess that depends 
on whether they can be parameterized in some way such that it would make 
sense to have more than one. I suppose the simplest answer is to declare 
that this won't be supported. Then the id isn't needed.

> response, and get a negotiated set of packages in the ACK.

AMEN!

> INVITE transaction, and there is no re-negotiation.      [Is that ok?  
> Is there a need to have re-negotiation? (is there a   use case?)  It 
> sure makes it simple not to have things change in the   middle of a 
> session]
> 

A hybrid of the two above is a PSTN GW, where a call transfer happens on 
the PSTN side.

> ----
> 
>   If an Invite usage fails or is terminated, the Info-based   event 
> state no longer exists, and an INFO request MUST NOT be sent.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Nov 2007 08:14:31 -0500

Thanks for the great feedback Adam - comments inline...

> Sent: Tuesday, November 27, 2007 5:07 PM
>
# that statement is su-perl-ative
print "will do\n";

> paragraph of section 5.1).

My take on this is that ISUP/QSIG use of INFO is not Info-Package use, and so follows its own rules (though we should have said so).  If this draft becomes a replacement for 2976, however, then that's a bigger deal.  So yeah I agree, regardless.

> consensus on that topic would take more than a little work. [...snip]

What do you mean about "grandfathering DTMF"?  (are you reading that in the draft somewhere?)  I'm confused.

> response, and get a negotiated set of packages in the ACK.

I'm trying to understand some specific scenarios you're worried about.  Can you describe the scenarios with examples why the 3PCC model breaks here? (I don't doubt they exist - I just don't see it)

> warrant a change in available packages.

Yeah for those I can see re-Invite really should re-negotiate Info-package support.  (But still not clear on why we need delayed indications of supported Info-packages.)

> situations) and how it should be handled.

Yeah good point.

> I think you mean "1xx", not "18x"

Yup.

> section 4.4 and its subsections).

Is there any such "appropriate rates" discussion in other Request Method RFCs? (other than specific mechanisms such as session-expires)  I mean wouldn't that be part of the package definition to deal with, if at all?

> if I *want* the call to fail if a specific package isn't supported?"

Yeah, so I think that begs the question if we should care about that case.  Like there is no real way to signal such for many media-related items.  For example you can offer 2833, but you can't do "reject this request if you're not going to answer me 2833", and no one's complained this was needed (right?).

> least OPTIONS (and, to a lesser degree, REGISTER) would be a very useful

That last sentence was the big question - assuming that holds, we would definitely put in explicit wording around it.

> boilerplate out of 2976, it comes to only a couple pages in length).

Agreed.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Wed, 28 Nov 2007 10:59:12 -0600

> What do you mean about "grandfathering DTMF"?  (are you reading that in the draft somewhere?)  I'm confused.

The comment was meant in the context of grandfathering existing uses of 
INFO, and DTMF is the elephant in the room. The more general advice 
would be: "be careful in discussion of grandfathering existing INFO uses 
that you only include well-defined uses -- otherwise, you'll find 
yourself having to provide the detailed definition of such uses."

> I'm trying to understand some specific scenarios you're worried about.  Can you describe the scenarios with examples why the 3PCC model breaks here? (I don't doubt they exist - I just don't see it)

Basically, I think you'll run into problems if you can't support a 
scenario like this:

          A                 3PCC                  B
          |(1) INVITE         |                   |
          |(no Recv-Info)     |                   |
          |<------------------|                   |
          |(2) 200            |                   |
          |(Recv-Info A)      |                   |
          |------------------>|                   |
          |                   |(3) INVITE         |
          |                   |(Recv-Info A)      |
          |                   |------------------>|
          |                   |(4) 200            |
          |                   |(Send-Info A)      |
          |                   |<------------------|
          |                   |(5) ACK            |
          |                   |------------------>|
          |(6) ACK            |                   |
          |(Send-Info A)      |                   |
          |<------------------|                   |
          |(7) Media          |                   |
          |.......................................|
          |                   |(8) INFO           |
          |                   |<------------------|
          |(9) INFO           |                   |
          |<------------------|                   |

Without the ability to negotiate Info Packages in messages (2) and (5), 
you run into the basic inability to support this kind of thing.

> Yeah for those I can see re-Invite really should re-negotiate Info-package support.  (But still not clear on why we need delayed indications of supported Info-packages.)

Beyond those use cases, you should keep the following flow in mind as 
well, which requires the ability to renegotiate Info Packages in re-INVITEs:

          A                 3PCC                  B
          |(1) INVITE         |                   |
          |(no Recv-Info)     |                   |
          |<------------------|                   |
          |(2) 200            |                   |
          |(Recv-Info A)      |                   |
          |------------------>|                   |
          |(3) ACK            |                   |
          |(no Send-Info)     |                   |
          |<------------------|                   |
          |                   |(4) INVITE         |
          |                   |(Recv-Info A)      |
          |                   |------------------>|
          |                   |(5) 200            |
          |                   |(Send-Info A)      |
          |                   |<------------------|
          |(6) INVITE         |                   |
          |(Send-Info A)      |                   |
          |<------------------|                   |
          |(7) 200            |                   |
          |(Recv-Info A)      |                   |
          |------------------>|                   |
          |                   |(8) ACK            |
          |                   |------------------>|
          |(9) ACK            |                   |
          |<------------------|                   |
          |(10) Media         |                   |
          |.......................................|
          |                   |(11) INFO          |
          |                   |<------------------|
          |(12) INFO          |                   |
          |<------------------|                   |

This actually highlights another very interesting point -- to make this 
flow work at all, A needs to indicate the Info Packages it is willing to 
send and receive in message (2), regardless of whether such packages 
appeared in message (1) at all. In other words, what appears in a 200 
can't be a subset of what was in the INVITE -- it should be a statement 
of absolute capabilities.

> Is there any such "appropriate rates" discussion in other Request Method RFCs? (other than specific mechanisms such as session-expires)  I mean wouldn't that be part of the package definition to de…

If you plan for that to be the case, say so in the document. I suggest 
copying the first paragraph of RFC 3265, section 4.4.10, and the final 
paragraph of section 4.1, with appropriate changes in terminology.

> Yeah, so I think that begs the question if we should care about that case.  Like there is no real way to signal such for many media-related items.  For example you can offer 2833, but you can't do…

I won't object one way or the other. I'm trying to make your life easier 
-- the arguments here are predictable, and my suggestion is an attempt 
to ward them off. You can ignore mu suggestion and I'll stay out of the 
way, but I doubt others will. I'll close by quoting an example already 
being given in this area (from Eric's draft):

  "Some uses of INFO can tolerate this fate sharing of the INFO message
   over the entire dialog.  For example, in the SIP-T usage, it may be
   acceptable for a call to fail, or to tear down the call, if one
   cannot deliver the associated SS7 information."

> That last sentence was the big question - assuming that holds, we would definitely put in explicit wording around it.

I think we'd be muddling things up pretty badly if we suddenly started 
defining aspects of the protocol that are not discoverable via OPTIONS, 
but could be discovered via alternate means (e.g. INVITE). It's kind of 
changing the meaning of "OPTIONS".

The REGISTER usage isn't as clear cut. The reason I think it would be 
nice to have is that it allows me to come along later and define a 
caller-prefs that says, "I'm trying to reach Hadriel, and I'd prefer if 
I could reach him on a device that supports event package foo."

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Nov 2007 14:18:06 -0500

> Sent: Wednesday, November 28, 2007 11:59 AM
>

I apologize, I didn't mean I didn't get the call flow - I just didn't get why it should work that way for info-packages.  But I think I understand now.  I was thinking info-package requires the UA to understand the package, and a 3PCC is a B2BUA, hence a UA - and so would need to know them a priori and thus be able to indicate what packages it supports in Invite-1.  Somewhat akin to Supported/Require usage.  But clearly that no workie. (duh)

But, I do think there are multiple options for dealing with this:

Option 1) support the basic model of offer/answer a la SDP.

Option 2) since we'll support re-negotiation in re-Invite anyway, force 3PCC or any such blind Invite initiator to offer all in the invite, and re-negotiate in a re-Invite when it knows more.

Option 3) do what you basically said later in your email: make send-info/recv-info purely an announcement not a negotiation.  It can be changed at will, sent in any message, etc.  Someone actually raised this model before (maybe Dean?).

The reason I'm even suggesting Option 2 is it (a) seems simpler to me from a KISS/high-level-logic perspective (and thus hopefully easier for implementers and fewer "bugs"), (b) I've seen numerous issues with SDP delayed offers in the field, and (c) I'm thinking the burden of handling 3PCC cases should be placed on 3PCC controllers, not by complicating the logic for all others.  But I'm not sure how "offering all" would really work.  I mean you could define some token/syntax that means it, but I would think that would be dangerous.  Option 3 seems to have these same properties to me as well and more, without this last problem.

But Option 3 I thought had some issue but I can't remember what it is now. (probably related to DTMF use?)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2007 16:02:30 -0500

Inline...

> Option 1) support the basic model of offer/answer a la SDP.

Don't get stuck on the analogy to SDP O/A. There are relationships but 
they are not the same thing. The specification of O/A in 3264 doesn't 
even map it to SIP messages.

Its the basic notion of being able to make an offer in the invite or 
solicit an offer in the invite that provides both the power and the pain.

> Option 2) since we'll support re-negotiation in re-Invite anyway, force 3PCC or any such blind Invite initiator to offer all in the invite, and re-negotiate in a re-Invite when it knows more.

For 3pcc, where the existing mechanism must be handled for SDP, a 
mechanism that requires additional messages would at least be annoying 
and inconvenient if it can be accomplished with the existing messages.

> But Option 3 I thought had some issue but I can't remember what it is now. (probably related to DTMF use?)

It seems to me that there is a need to know what *will* be used as well 
as what *could* be used. This is especially the case when there are 
multiple possible mechanisms to accomplish the same thing and one is 
being chosen. That is the situation with DTMF.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Nov 2007 16:28:19 -0600

On Nov 28, 2007, at 3:02 PM, Paul Kyzivat wrote:
>
> It seems to me that there is a need to know what *will* be used as  
> well as what *could* be used. This is especially the case when  
> there are multiple possible mechanisms to accomplish the same thing  
> and one is being chosen. That is the situation with DTMF.
>
>

I'm still thinking at the level of what "MAY" be used. We don't know  
what "will" be used until it happens. Sometimes those decisions  
aren't made until runtime -- and sometimes, they never get made at all.

As Douglas Adams points out, the invention of time travel will have  
caused a change to human language, eliminating the future perfect  
tense, as the future will have been found not to have been perfect.  
Or something like that.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2007 17:46:50 -0500

Dean,

I agree that "will" is problematic, but I was having trouble coming up 
with a suitable word. Maybe I can just use a lot of words instead:

Instead of *could* be used, perhaps "capable of using" is better. 
Equivalent to Supported.

By *may* I meant that if there is a need to signal this sort of thing, 
then this mechanism MUST be used to do it.

So, Alice says:

   I am capable of sending and receiving DTMF via this INFO technique.
   (And at the same time may also be offering the telephone-events
   payload type in the SDP.)

And then Bob says:

   I am capable of sending DTMF via this INFO technique.
   I select that this INFO technique will be the technique I use to
   send DTMF to you. I don't receive DTMF this way, so don't send it
   to me.
   (And at the same time rejects the telephone-events
   payload type in the SDP answer.)

	Paul

Dean Willis wrote:
>> well as what *could* be used. This is especially the case when there 
>> are multiple possible mechanisms to accomplish the same thing and one 
>> is being chosen. That is the situation with DTMF.
>>
>>
> 
> what "will" be used until it happens. Sometimes those decisions aren't 
> made until runtime -- and sometimes, they never get made at all.
> 
> caused a change to human language, eliminating the future perfect tense, 
> as the future will have been found not to have been perfect. Or 
> something like that.
> 
> -- 
> Dean
>

---

From: "Michael Procter" <[email-masked]>
Date: Thu, 29 Nov 2007 06:27:47 -0800

Just to pick up on one of the comments:

>> I think you mean "1xx", not "18x"

Can this be extended to permit Send-Event and Recv-Event to be optional in non-2xx final responses too?  The reason is simple: OPTIONS can be rejected with a 486 simply because the UA is on a call.  Under those circumstances, I think it would still be useful to know what the UA supports.  (There are probably other responses where it would be useful - I am simply trying to make the point, rather than list all relevant responses at this stage.)
 
I know that a proxy consolidating responses from a forked OPTIONS might seem to make this less useful, but an OPTIONS sent to a gruu wouldn't suffer from this problem, and so would remain useful.
 
Regards,
 
Michael

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 29 Nov 2007 17:40:46 +0100

Hi,

I don't think it would harm to allow the headers in pretty much any
response - in case we come up with use-cases (like the one you just
presented) in future where it is needed.

Regards,

Christer 

> From: Michael Procter [mailto:[email-masked]] 
> Sent: 29. marraskuuta 2007 16:28
> To: Hadriel Kaplan; Adam Roach
> Can this be extended to permit Send-Event and Recv-Event to 
> be optional in non-2xx final responses too?  The reason is 
> simple: OPTIONS can be rejected with a 486 simply because the 
> UA is on a call.  Under those circumstances, I think it would 
> still be useful to know what the UA supports.  (There are 
> probably other responses where it would be useful - I am 
> simply trying to make the point, rather than list all 
> relevant responses at this stage.)
>  
> I know that a proxy consolidating responses from a forked 
> OPTIONS might seem to make this less useful, but an OPTIONS 
> sent to a gruu wouldn't suffer from this problem, and so 
> would remain useful.
>  
> Regards,
>  
> Michael
>