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

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

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