[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Comments on draft-kaplan-sip-info-events-01
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
tFrom sip-bounces at ietf.org Wed Aug 20 08:44:03 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id AEA9C3A6C44;
Wed, 20 Aug 2008 08:44:03 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 7BF3528C1A1
for <sip at core3.amsl.com>; Wed, 20 Aug 2008 08:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id mGRssahGvgrS for <sip at core3.amsl.com>;
Wed, 20 Aug 2008 08:44:01 -0700 (PDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk
[195.171.110.225])
by core3.amsl.com (Postfix) with ESMTP id 618243A6C44
for <SIP at ietf.org>; Wed, 20 Aug 2008 08:44:01 -0700 (PDT)
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
with ESMTP id <0K5W00JBXOWZSK at siemenscomms.co.uk> for SIP at ietf.org; Wed,
20 Aug 2008 16:43:31 +0100 (BST)
Date: Wed, 20 Aug 2008 16:43:17 +0100
From: "Elwell, John" <john.elwell at siemens.com>
To: SIP IETF <SIP at ietf.org>, Hadriel Kaplan <HKaplan at acmepacket.com>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0010197C4 at GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Thread-Topic: Comments on draft-kaplan-sip-info-events-01
Thread-Index: AckC23b9bFmfOjwGSiGwd9GuRptGlw==
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Subject: [Sip] Comments on draft-kaplan-sip-info-events-01
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
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, he 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip