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

["DRAGE, Keith \(Keith\)" <drage at alcatel-lucent.com>]

All I am saying here is that a package needs to define what mechanism it
uses to ensure that it has received things in order, assuming that it
matters. My assumption was that this would be package specific, and
dependent on the application.  I was then calling for the template for a
package definition to provide a space for the package definer to specify
this.

There is nothing in the INFO RFC as far as I recall that prevents
multiple INFO messages being in flight at the same time. Additionally
items can be delivered out of order.

One mechanism that may work in some applications, may be to ensure that
a new INFO is not sent until a final response has been received to the
previous one sent. Alternatively, as Christer has said, pay attention to
the Cseq, however straight increments will not work as some other
message could have been sent in between. It probably therefore cannot be
used as a mechanism to determine that an INFO payload has been lost.

By the way, does the proposal cover usage of multiple packages
simultaneously within the same dialog, each with their own sequencing
requirements. If so, that probably adds a further round of complexity.

Keith

> -----Original Message-----
> From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly at att.com] 
> Sent: Sunday, December 02, 2007 3:41 PM
> To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat); DRAGE, 
> Keith (Keith)
> Cc: sip at ietf.org
> Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00
> 
> Wait a minute. Simply put the issue here is whether the 
> complexity is at the edge element or device versus in the 
> application server. Either one needs to correlate and put the 
> digits in order. 
> 
> -----Original Message-----
> From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh at cisco.com]
> Sent: Sunday, December 02, 2007 10:22 AM
> To: Paul Kyzivat (pkyzivat); DRAGE, Keith (Keith)
> Cc: sip at ietf.org
> Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00
> 
> Inline ...
> 
> >-----Original Message-----
> >From: Paul Kyzivat (pkyzivat)
> >Sent: Saturday, December 01, 2007 2:31 PM
> >To: DRAGE, Keith (Keith)
> >Cc: sip at ietf.org
> >Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00
> >
> >Keith,
> >
> >A comment about one of your points:
> >
> >DRAGE, Keith (Keith) wrote:
> >
> >> 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.
> 
> But if the INFO is used for dtmf, the rejected request will 
> be a problem as it will result in loss of digit information. 
> So I think package type should define whether it is ok to 
> send overlapping requests or not.
> 
> Sanjay
> 
> >
> >The end result is that you can get *nondelivery* of a 
> message, but not 
> >*out of order delivery*.
> >
> >	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
> 
> 
> _______________________________________________
> 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