RE: [Sip] Comments on draft-kaplan-sip-info-events-00

[Hadriel Kaplan <HKaplan at acmepacket.com>]

Yup, fair enough.
-hadriel


> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com]
> Sent: Sunday, December 02, 2007 4:58 PM
> To: Hadriel Kaplan; Paul Kyzivat; Christer Holmberg
> Cc: sip at 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 at acmepacket.com]
> > Sent: Sunday, December 02, 2007 7:17 PM
> > To: Paul Kyzivat; Christer Holmberg
> > Cc: sip at 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 at cisco.com]
> > > Sent: Sunday, December 02, 2007 12:17 PM
> > > To: Christer Holmberg
> > > Cc: sip at 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 at cs.columbia.edu for questions on current sip Use
> > > > sipping at 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 at cs.columbia.edu for questions on current sip Use
> > > sipping at 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 at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip