[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VS: [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