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

[Hadriel Kaplan <[e-mail]>]

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:[e-mail]]
> Sent: Sunday, December 02, 2007 12:17 PM
> To: Christer Holmberg
> Cc: [e-mail]; 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 [e-mail] for questions on current sip
> > Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip