RE: [Sip] Comments on draft-kaplan-sip-info-events-00
Hadriel Kaplan <HKaplan@acmepacket.com> Mon, 03 December 2007 05:15 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 1Iz3eK-0003YI-Ui; Mon, 03 Dec 2007 00:15:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz3eJ-0003Y4-Ms for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 00:15:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3eJ-0003Xp-D8 for sip@ietf.org; Mon, 03 Dec 2007 00:15:19 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz3eI-000202-Ol for sip@ietf.org; Mon, 03 Dec 2007 00:15:19 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Mon, 3 Dec 2007 00:15:18 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 3 Dec 2007 00:15:15 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, Paul Kyzivat <pkyzivat@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Date: Mon, 03 Dec 2007 00:15:11 -0500
Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00
Thread-Topic: [Sip] Comments on draft-kaplan-sip-info-events-00
Thread-Index: Acg1B1WRC/zr5GFgSA+QxSJOhIe7uQADsx8QAAX5nMAADua0MA==
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC30273297659@mail.acmepacket.com>
References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com><4751B684.7060603@cisco.com><CA9998CD4A020D418654FCDEF4E707DFEE08AC@esealmw113.eemea.ericsson.se> <4752E89B.1040800@cisco.com> <E6C2E8958BA59A4FB960963D475F7AC302732975AB@mail.acmepacket.com> <5D1A7985295922448D5550C94DE29180019B77C0@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180019B77C0@DEEXC1U01.de.lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Cc: "sip@ietf.org" <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
Yup, fair enough. -hadriel > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Sunday, December 02, 2007 4:58 PM > To: Hadriel Kaplan; Paul Kyzivat; Christer Holmberg > Cc: sip@ietf.org > Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 > > 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