RE: [Sip] Comments on draft-kaplan-sip-info-events-00
"DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com> Sun, 02 December 2007 21:59 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iywqd-00073v-L4; Sun, 02 Dec 2007 16:59:35 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iywqc-000733-JI for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 16:59:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iywqc-00072o-9K for sip@ietf.org; Sun, 02 Dec 2007 16:59:34 -0500
Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iywqb-0005eS-HT for sip@ietf.org; Sun, 02 Dec 2007 16:59:34 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lB2LwWdq018366; Sun, 2 Dec 2007 15:58:32 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 15:58:32 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 22:58:30 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00
Date: Sun, 02 Dec 2007 22:58:28 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180019B77C0@DEEXC1U01.de.lucent.com>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC302732975AB@mail.acmepacket.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Comments on draft-kaplan-sip-info-events-00
Thread-Index: Acg1B1WRC/zr5GFgSA+QxSJOhIe7uQADsx8QAAX5nMA=
References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com><4751B684.7060603@cisco.com><CA9998CD4A020D418654FCDEF4E707DFEE08AC@esealmw113.eemea.ericsson.se> <4752E89B.1040800@cisco.com> <E6C2E8958BA59A4FB960963D475F7AC302732975AB@mail.acmepacket.com>
From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, Paul Kyzivat <pkyzivat@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>
X-OriginalArrivalTime: 02 Dec 2007 21:58:30.0565 (UTC) FILETIME=[79A47D50:01C8352E]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
I don't think we can be as categorical as that, due to the fact that we don't know what will exist in the future. That was why I went for suggesting it should be defined by the application using the package. We can identify the problems that exist - if it matters, it is up to the package designer to specify the fix it (probably within the transported data itself unless the solution of not sending another INFO until a final response to the previous is received works). Regards Keith > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Sunday, December 02, 2007 7:17 PM > To: Paul Kyzivat; Christer Holmberg > Cc: sip@ietf.org; DRAGE, Keith (Keith) > Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 > > I think we're getting wrapped around an issue that just > doesn't matter. The probability of this case is very small, > and even if it happens so what? It's like a DTMF tone got > lost. The user has to re-enter their digits. That happens > regularly in the real world with cell phones, with 2833, and > could happen with KPML (I think). As long as it's a rare > occurrence per user, it doesn't really matter. > > -hadriel > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Sunday, December 02, 2007 12:17 PM > > To: Christer Holmberg > > Cc: sip@ietf.org; DRAGE, Keith (Keith) > > Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 > > > > > > > > Christer Holmberg wrote: > > > Hi, > > > > > >>> In particular, one area which needs to be covered is how the > > >>> embedded information tranfer caters for out of sequence > delivery, > > >>> given that the carriage mechanism does not guarantee order > > of > > >>> delivery in all circumstances of SIP usage. > > >> I'm wondering what you have in mind here. > > >> > > >> It is possible to send request R1 then send R2 before getting a > > response > > >> to R1. And then it is possible for R2 to arrive before > R1, and in > > >> that case it will be accepted. But then, when R1 arrives > there will > > >> be a > > CSeq > > >> error so it will be rejected. > > >> > > >> The end result is that you can get *nondelivery* of a > message, but > > >> not *out of order delivery*. > > > > > > The problem is that if the receiver receives a message > with Cseq=X, > > > it > > doesn't matter whether it will receive Cseq=X-1 later, because CSeq > > doesn't have to be incremented by one. > > > > I'm not sure if we are agreeing or talking past one another. > > > > If R1 is sent with Cseq=X and R2 is sent with Cseq=X+1, and R2 is > > received first, it will be considered a valid request even though > > there was a gap in the Cseq numbering. Then, when R1 > finally arrives, > > its Cseq will be too small, so the request will be rejected. > > > > > I guess the question is: > > > > > > Shall it be possible to send a new INFO with the SAME > Info Package > > > type > > as in an ongoing INFO transaction? > > > > > If you have negotiated multiple Info Package types, being > forced to > > > only > > have one outstanding INFO transaction is too restrictive, I think. > > > > It doesn't matter if it is the same info package type or > not. This is > > a fundamental problem with sending multiple requests > concurrently in a > > dialog. There is nothing you can do in the specification of > INFO that > > will improve on this. > > > > Fixing that would require changing the basic nature Cseq > processing in > > 3261. I don't know about you, but I am not going to recommend that. > > > > Rather, I think the restriction to one outstanding > transaction must be > > accepted as a limitation of using the INFO technique. > > > > Paul > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > Thanks, > > > Paul > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Comments on draft-kaplan-sip-info-events-00 DRAGE, Keith (Keith)
- Re: [Sip] Comments on draft-kaplan-sip-info-event… Paul Kyzivat
- VS: [Sip] Comments on draft-kaplan-sip-info-event… Christer Holmberg
- VS: [Sip] Comments on draft-kaplan-sip-info-event… Christer Holmberg
- RE: [Sip] Comments on draft-kaplan-sip-info-event… Sanjay Sinha (sanjsinh)
- RE: [Sip] Comments on draft-kaplan-sip-info-event… DOLLY, MARTIN C, ATTLABS
- Re: VS: [Sip] Comments on draft-kaplan-sip-info-e… Paul Kyzivat
- Re: [Sip] Comments on draft-kaplan-sip-info-event… Paul Kyzivat
- RE: [Sip] Comments on draft-kaplan-sip-info-event… Hadriel Kaplan
- VS: VS: [Sip] Comments on draft-kaplan-sip-info-e… Christer Holmberg
- RE: [Sip] Comments on draft-kaplan-sip-info-event… DRAGE, Keith (Keith)
- RE: [Sip] Comments on draft-kaplan-sip-info-event… DRAGE, Keith (Keith)
- RE: [Sip] Comments on draft-kaplan-sip-info-event… DRAGE, Keith (Keith)
- RE: [Sip] Comments on draft-kaplan-sip-info-event… Hadriel Kaplan
- Re: [Sip] Comments on draft-kaplan-sip-info-event… Dean Willis
- Re: [Sip] Comments on draft-kaplan-sip-info-event… Adam Roach
- Re: [Sip] Comments on draft-kaplan-sip-info-event… Dale.Worley
- Re: [Sip] Comments on draft-kaplan-sip-info-event… Dean Willis