FW: I-D Action:draft-kaplan-sip-info-events-00.txt

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: Internet-Draftsietf.org
[mailto:Internet-Draftsietf.org]
> Sent: Thursday, November 08, 2007 11:00 PM
> To: i-d-announceietf.org
> 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
> i-d-announce-requestietf.org with the word
unsubscribe in the body of
> the message.
> You can also visit h
ttps://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/s
hadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         mailservietf.org.
> 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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplanacmepacket.com] 
> Sent: 19. marraskuuta 2007 23:07
> To: Adam Roach
> Cc: sipietf.org; Christer Holmberg
> 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
> 
> 
> > -----Original Message-----
> > From: Adam Roach [mailto:adamnostrum.com]
> > Sent: Monday, November 19, 2007 3:57 PM
> > To: Hadriel Kaplan
> > Cc: sipietf.org; Christer Holmberg
> > Subject: Re: [Sip] FW: I-D 
> Action:draft-kaplan-sip-info-events-00.txt
> >
> > 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:
> > > 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: Internet-Draftsietf.org
[mailto:Internet-Draftsietf.org]
> > >> Sent: Thursday, November 08, 2007 11:00
PM
> > >> To: i-d-announceietf.org
> > >> 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-kap
lan-sip-info-events-00
> > >> .txt
> > >>
> > >> To remove yourself from the I-D
Announcement list, send 
> a message 
> > >> to i-d-announce-requestietf.org
with the word 
> unsubscribe in the 
> > >> body of the message.
> > >> You can also visit 
> > >> h
ttps://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/s
hadow.html or 
> > >>
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >>
> > >> Internet-Drafts can also be obtained by
e-mail.
> > >>
> > >> Send a message to:
> > >>         mailservietf.org.
> > >> 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://ww
w1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core
SIP Protocol Use 
> > > sip-implementorscs.columbia.edu for
questions on current sip Use 
> > > sippingietf.org for new developments on the
application of sip
> 
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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


> -----Original Message-----
> From: Adam Roach [mailto:adamnostrum.com]
> Sent: Tuesday, November 27, 2007 5:07 PM
>
> General nit: s/header/header field/g
# that statement is su-perl-ative
print "will don";

> 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).

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.


> 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. [...snip]

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


> 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.

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)


> 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.

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.)


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

Yeah good point.

>    Recv-Event          18x        -   -   -   o   o   -
  -
> I think you mean "1xx", not "18x"

Yup.

> 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).

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?


> 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?"

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?).


> 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.

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


> 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).

Agreed.

-hadriel


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

> -----Original Message-----
> From: Adam Roach [mailto:adamnostrum.com]
> Sent: Wednesday, November 28, 2007 11:59 AM
>
> 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.

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



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Just to pick up on one of the comments:

Hadriel Kaplan wrote:
> From: Adam Roach [mailto:adamnostrum.com]
>>    Recv-Event          18x        -   -   -   o   o
  -   -
>> I think you mean "1xx", not
"18x"
>
> Yup.

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


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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 

> -----Original Message-----
> From: Michael Procter [mailto:michael.proctercitel.com] 
> Sent: 29. marraskuuta 2007 16:28
> To: Hadriel Kaplan; Adam Roach
> Cc: sipietf.org; Christer Holmberg
> Subject: RE: [Sip] FW: I-D
Action:draft-kaplan-sip-info-events-00.txt
> 
> Just to pick up on one of the comments:
> 
> Hadriel Kaplan wrote:
> > From: Adam Roach [mailto:adamnostrum.com]
> >>    Recv-Event          18x        -   -   -  
o   o   -   -
> >> I think you mean "1xx", not
"18x"
> >
> > Yup.
> 
> 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
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip