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

["DRAGE, Keith \(Keith\)" <drage at alcatel-lucent.com>]

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