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

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi Paul,

>>>> 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.

I think we agree. I shouldn't have sent my e-mail after 35 hours without sleep :)

>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.

Yes.

What I had in mind is whether we would need some additional sequence number, which is always incremented by one -similar to what we have for PRACK. In that case the receiver would know that there is supposed to come something before R2, so it would not accept R2 unti it has received R1.

But, before we start looking into such things I think we need to consider whether it is really needed. It could also be defined as an extension in future (it doesn't even have to be INFO specific, so).

Regards,

Christer




_______________________________________________
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