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

[Paul Kyzivat <[e-mail]>]

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