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

From: Paul Kyzivat <[email-masked]>
Date: Sat, 01 Dec 2007 14:31:16 -0500

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.

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 2 Dec 2007 12:55:21 +0100

Hi,

I agree with you that there are still things missing. I have listed a number of issues in my slides, based on the comments I've got.
 
Some comments inline.

>If we go with this approach, then I would note that there are a number
>of additional issues we need to address, for which material is not yet
>on the table:
>
>1)      We should provide guidance as to when it is appropriate to
>define an INFO package and when some other mechanism should be used.
>draft-burger-sip-info-02.txt is one extreme of this which says NEVER.
>This guidance will need to be taken account of by any review process
>(whatever it is) for IANA registration.

I agree it would be good to have some words about this.

>2)      The registry of packages has to exist. Need to define the review
>requirements for adding to the registry.

Yes. This is one of the things I'd thought we handle once we have agreed whether we are going to go forward with the draft in the first place, though :)

>3)      There should be a template associated with such packages. This
>should prompt the definer of a new package to specify all issues that
>should be covered.

Yes. This is listed as an issue in my slides.

>delivery in all circumstances of SIP usage.

Good point. I will add that to the issues. I guess we have two possibilities: either we define some kind of sequence number, or we mandate to only have one outstanding INFO transaction at a time - which I think could be too restrictive.

>4)      RFC 2976 still references the obsolete SIP RFC, and therefore
>presumably operates to the state machine defined in that RFC, rather
>than the one in RFC 3261. If we are going to resurrect INFO, then
>presumably we need to replace RFC 2976 with either this draft, or a
>companion draft, rather than just update it.

Yes. The possible replacement of 2976 by the draft is covered in my slides.

>5)      Do we define packages for ISUP and QSIG?

It is an issue also covered in my slides, and the question is really whether we need to do something.

First, we already have standardized, and deployed, mechanisms for ISUP and QSIG transport.

Second, ISUP and QSIG may also be sent in the initial INVITE, before you have done the Info Package negotiation, and also in other non-INFO messages.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 2 Dec 2007 12:56:14 +0100

Hi,

>The end result is that you can get *nondelivery* of a message, but not
 
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

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sun, 2 Dec 2007 10:22:00 -0500

Inline ...

>-----Original Message-----
>From: Paul Kyzivat (pkyzivat) 
>Sent: Saturday, December 01, 2007 2:31 PM
>To: DRAGE, Keith (Keith)
>Cc: [email-masked]
>Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00
>
>Keith,
>
>> 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.
>
>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
>
>
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sun, 2 Dec 2007 10:41:24 -0500

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:[email-masked]] 
Sent: Sunday, December 02, 2007 10:22 AM
To: Paul Kyzivat (pkyzivat); DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00

Inline ...

Sanjay

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Dec 2007 12:17:15 -0500

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

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Dec 2007 12:34:57 -0500

I think iw will have to be a responsibility of the sending UA to 
serialize all things that need to travel via INFO.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 2 Dec 2007 14:16:58 -0500

I think we're getting wrapped around an issue that just doesn't matter.  The probability of this case is very small, and even if it happens so what?  It's like a DTMF tone got lost.  The user has to re-enter their digits.  That happens regularly in the real world with cell phones, with 2833, and could happen with KPML (I think).  As long as it's a rare occurrence per user, it doesn't really matter.

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Sunday, December 02, 2007 12:17 PM
> To: Christer Holmberg
> Cc: [email-masked]; DRAGE, Keith (Keith)
> > 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.
>
> > If you have negotiated multiple Info Package types, being forced to only
> have one outstanding INFO transaction is too restrictive, I think.
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 2 Dec 2007 21:59:13 +0100

Hi Paul,

>>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 think we agree. I shouldn't have sent my e-mail after 35 hours without sleep :)

>If you have negotiated multiple Info Package types, being forced to only have one outstanding INFO transaction is too >restrictive, I think.
>

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

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 2 Dec 2007 22:10:47 +0100

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

> From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
> Sent: Sunday, December 02, 2007 3:41 PM
> To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat); DRAGE, 
> Keith (Keith)
> Cc: [email-masked]
> 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. 
> 
> >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
> 
> >
> >[email-masked] for questions on current sip Use 
> >[email-masked] for new developments on the application of sip
> >
> 
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 2 Dec 2007 22:28:04 +0100

Working backwards through my mailbox, and I guess I should have read this first.

Yes, what I had in mind was the non-delivery of packets, e.g. for the reason of non-sequential delivery.

SIP will not tell you you have missed any packets in this case.

Regards

Keith 

> Sent: Saturday, December 01, 2007 7:31 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> > In particular, one area which needs to be covered is how 
> the embedded 
> The end result is that you can get *nondelivery* of a 
> message, but not *out of order delivery*.
> 
> 	Thanks,
> 	Paul
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 2 Dec 2007 22:58:28 +0100

I don't think we can be as categorical as that, due to the fact that we
don't know what will exist in the future.

That was why I went for suggesting it should be defined by the
application using the package. We can identify the problems  that exist
- if it matters, it is up to the package designer to specify the fix it
(probably within the transported data itself unless the solution of not
sending another INFO until a final response to the previous is received
works).

Regards

Keith

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Sunday, December 02, 2007 7:17 PM
> To: Paul Kyzivat; Christer Holmberg
> I think we're getting wrapped around an issue that just 
> doesn't matter.  The probability of this case is very small, 
> and even if it happens so what?  It's like a DTMF tone got 
> lost.  The user has to re-enter their digits.  That happens 
> regularly in the real world with cell phones, with 2833, and 
> could happen with KPML (I think).  As long as it's a rare 
> occurrence per user, it doesn't really matter.
> 
> -hadriel
> 
> 
> > >>> embedded information tranfer caters for out of sequence 
> delivery, 
> > >>> given that the carriage mechanism does not guarantee order
> > of
> > 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
> > > The problem is that if the receiver receives a message 
> with Cseq=X, 
> > > it
> > 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
> > 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 3 Dec 2007 00:15:11 -0500

Yup, fair enough.
-hadriel

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Sunday, December 02, 2007 4:58 PM
> To: Hadriel Kaplan; Paul Kyzivat; Christer Holmberg
> Cc: [email-masked]

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 Dec 2007 00:30:56 -0600

> SIP will not tell you you have missed any packets in this case.

But if the sender follows basic NIT rules and doesn't overlap  
transactions within the dialog, then you'll never have out-of-order  
delivery. If you're sending ordered delivery, don't send packet 2  
until packet 1 gets ACKed.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Mon, 03 Dec 2007 10:43:46 -0800

> until packet 1 gets ACKed.

I had it in my head many years ago that overlapping NITs were illegal 
also, but I couldn't ever find any supporting text in RFCs. I think it 
was in some pre-publication versions of 2543-bis, but got pulled out 
before finalization.

/a

---

From: [email-masked]
Date: Mon, 3 Dec 2007 15:36:19 -0500

From: Adam Roach <[email-masked]>

I think that overlapped transactions is a basic feature of SIP.  (The
UAC has to be able to deal with the occasional 500 Out Of Order
situation, of course.)

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 Dec 2007 16:13:15 -0600

> UAC has to be able to deal with the occasional 500 Out Of Order

Yes, but just because the protocol can handle overlapped NITs doesn't  
mean the application should send them that way. If you have  
sequential data that needs to be delivered in order (for example,  
MESSAGE requests) you have to sequence the requests at the  
application level.

--
Dean