Subject: [Sip] Issue #113, wrt Content Sequencing

From: "Eric Burger" <[email-masked]>
Date: Tue, 7 Aug 2001 06:14:13 -0400

On the one hand, I would love to find a generic mechanism for ordering and
detecting loss in overlapped non-INVITE content.  However, we hashed over
this issue in the SIP-events discussion.  Namely, content sequencing and
recovery is inherently content-specific.  Thus I would propose Strict
Sequencing (if needed) in the content, as Jonathan originally proposed.

---

From: "Ajay Chitturi" <[email-masked]>
Date: Mon, 27 Aug 2001 18:49:36 -0700

I think INFO is an example where such sequencing is required. It would be good to have a generic mechanism for providing ordering.

Ajay.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 12:19 PM
To: Jonathan Rosenberg
Cc: [email-masked]'; SIP List
Subject: Re: [Sip] Issue #113, wrt Content Sequencing

While an *average* rate of > 1/RTT probably calls for a real transport
protocol, it would be really nice to be able to send an occasional
message with a shorter spacing, particularly given the loss case (i.e.,
where it could be seconds before the answer comes back, thus delaying
the second message). Thus, I agree with Jonathan, that dumping this
feature could get us into trouble later. The increase in protocol
complexity seems close to zero and the increase in implementation
complexity modest.

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Eric Burger [mailto:[email-masked]]
> > Sent: Tuesday, August 07, 2001 6:14 AM
> > To: SIP List
> > Subject: [Sip] Issue #113, wrt Content Sequencing
> >
> >
> I think the first question we need to ask is whether we even want to solve
> the problem of overlapping non-INVITE.
> 
> One of the bigger motivating factors was the MESSAGE method. However, simple
> has converged upon NOT using MESSAGE for message transport in the session
> model. As a result, that need has disappeared.
> 
> Are there other burning needs? This is one of those things where there may
> not be a need now, but it could be a big issue down the road when someone
> comes up with a need.
> 
> Notifications for rapid presence changes, like second-granularity geo-loc
> updates, might be a need.
> 
> A more radical view is that if you want second-granular presence updates,
> you are better off setting up the notifications as a "media stream" as we
> are doing for IM, and use just SUBSCRIBE as is to set it up....
> 
> THoughts? Lets resolve this.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://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

_______________________________________________
Sip mailing list  http://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

_______________________________________________
Sip mailing list  http://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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Aug 2001 16:08:36 -0400

> Sent: Thursday, August 23, 2001 3:19 PM
> To: Jonathan Rosenberg

Clearly, its a cost/benefit thing. There is some cost, and there is some
benefit. The relative values of the costs and benefits will be entirely
subjective without some more concrete information.

So, I think a few questions still need to be answered:

1. Who has UA and/or proxy implementations which will be mightily upset at
seeing overlapping non-INVITE transactions within a call leg (in theory,
should be nobody, but I'm curious...) Is the complexity of buffering these
at the sender higher than the complexity of buffering at the receiver to
handle reordering?

2. What are some concrete use cases that people need? Can someone point out
some PSTN cases using INFO where we will legitimately need to send a second
INFO right away? Would performance really be hindered by buffering it?

-Jonathan R.

---