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

On 11/19/07 3:07 PM, Hadriel Kaplan 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.  :(
>   

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




_______________________________________________
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

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

	Thanks,
	Paul

Adam Roach wrote:
> On 11/19/07 3:07 PM, Hadriel Kaplan 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.  :(
>>   
> 
> 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.

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.

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

AMEN!

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

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