Subject: [Sip] Comments on draft-kaplan-sip-info-events-01

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Aug 2008 16:43:17 +0100

1. Section 6.1 includes a question whether it is OK to prohibit
Send-Info/Recv-Info in re-INVITE or UPDATE, and mentions that Adam
points out 3PCC needs it. I agree with Adam.

2. There is no provision for Send-Info/Recv-Info in 200/ACK (i.e.
omitting from an INVITE request, in the same way that SDP offer can be
omitted). It seems to me that some of the use cases that motivate INVITE
without SDP offer could also motivate INVITE without
Send-Info/Recv-Info. For example, a 3PCC make-call might need to do
this.

My remaining comments are more minor:
3. Information conveyed by INFO seems to be described in different ways,
e.g:
- "application level information"
- "session related control information"
- "mid-session signaling"
- "mid-session information"
We should be consistent, and my preference would be the first of these.

4. "This mechanism is not 
   appropriate for IANA-registered Subscribe Event package types, and 
   support for this mechanism should be explicitly indicated in future 
   Info Package definitions and registrations."
This sentence seems to be discussing two independent concepts, if I
understand correctly. It should be split in two.

5. Section 4 refers to Send-Info and Recv-Info without having introduced
these terms. Either they should be briefly introduced earlier or there
should be a forward reference to the section where they are introduced.

6. "INFO requests may be sent in either 
   direction, once the UAC or UAS has received the Send-Info/Recv-Info 
   header field value indications of what the far-end supports.  For 
   the UAS, it MUST receive the ACK for the INVITE's 200-ok, or the 
   PRACK for a provisional response, before sending an INFO request."
It seems that the second sentence is in conflict with the first. Is the
first sentence meant to be applicable only to a UAC?

7. I don't understand the logic behind the split between "4.2. Message
Body Inclusion" and "4.5. INFO Message Bodies".

8. Section 8.1.2 talks about message volume, and in particular suggests
that the mechanism is not suitable for data beyond the limits of typical
SIP messages. Perhaps it would also be worth noting the likelihood of
exceeding MTU size on UDP hops if large amounts of application data are
included.

9. Section 8.2.3 talks about defining INFO bodies as part of Info
Packages. However, elsewhere in the document it allows header fields to
be used to convey application data (if I understand correctly).
Shouldn't this be mentioned in 8.2 too?

John

_______________________________________________
Sip mailing list  https://www.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: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Aug 2008 12:21:36 -0400

> Send-Info/Recv-Info. For example, a 3PCC make-call might need to do

Yep. It is usually my role to remind people that it isn't done until it 
works with 3PCC. But thats true regardless of who does the reminding.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Thu, 21 Aug 2008 20:29:01 -0400

Good thing I'm not done with the update :-)
On Aug 20, 2008, at 12:21 PM, Paul Kyzivat wrote:

> Yep. It is usually my role to remind people that it isn't done until  
> it works with 3PCC. But thats true regardless of who does the  
> reminding.
>
> 	Thanks,
> 	Paul