Subject: RE: [Simple] Message session & associated dialog

From: [email-masked]
Date: Thu, 18 Jul 2002 17:28:03 +0300

> I am certainly not an expert on RTP, but elaborating on the
> RTP stream / MESSAGE stream comparison:
> RTP services certainly include sequence numbering.

Much of the reason RTP would have sequence numbering probably lies in the fact that the underlying transport protocol (UDP) provides no guarantees on sequential delivery of packets.

However, TCP does, so the message-session would only need the CSeq in MESSAGE to sequence overlapping requests. As far as I know, this is currently not allowed. 
 
Cheers,
Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 21 Jul 2002 14:30:11 +0900

Before I comment on this point below, let me state outright that I do 
NOT believe that the MESSAGE requests exist in any dialog. THe only 
dialog in existence is the one through INVITE. It was my belief that the 
"media stream" in this case was a sequence of what effectively look like 
page mode requests. However, I would like to provide sequencing for 
them, and so CSeq is natural for that. In order to use CSeq, you must 
have a well defined scope in which they exist. I had merely indicated 
that this was a "dialog ID" - meaning the To-tag, From-tag, and call-id, 
which does not imply the existence of a dialog.

More below:

[email-masked] wrote:
> Much of the reason RTP would have sequence numbering probably lies in
> the fact that the underlying transport protocol (UDP) provides no
> guarantees on sequential delivery of packets.
> 
> However, TCP does, so the message-session would only need the CSeq in
> MESSAGE to sequence overlapping requests. As far as I know, this is
> currently not allowed. 

With the existence of intermediary relays, you cannot guarantee 
end-to-end sequencing any longer.

However, it occurs to me that if the URI is the point of demux at the 
UAS, then the scope of the sequence numbers can be within that URI. In 
other words, each MESSAGE in the message media stream could (and 
probably should, thinking about this more) have a unique call-id. The 
cseq increment by one for each message sent by the originating UA. The 
UAS will provide a URI of sufficient uniqueness that it won't receive 
any messages at the URI except for ones sent by the originator. Thus, 
the cseq can provide ordering within the scope of the r-uri as seen by 
the UAS.

I think, however, we should focus on the bigger issue of whether this is 
really SIP, or whether we should go back to the older IMTP proposal. 
There was some debate on that during the meeting. I am still collecting 
thoughts on that, and welcome comments from others.

-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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Jul 2002 09:51:57 -0400

Jonathan Rosenberg wrote:
> page mode requests.

Good! 

It was my (mis)interpretation that you were suggesting otherwise that set off this thread.

> However, I would like to provide sequencing for

I'm unconfortable with using "dialog ID" without there being a dialog. I can't at the moment give a solid reason why this is wrong, but it feels like an abuse.

> the cseq can provide ordering within the scope of the r-uri as seen by

If we continue the analogy with RTP streams, then this seems like a bad assumption. In the case of RTP, we never assume that all the packets arrive from the same source.
This can be violated in many cases, such as when transferring a call, where one sender is replaced by another, but the receiver remains invariant.

Why can't we rely on the message content to provide ordering, and the reliablility of the transport to guarantee delivery? Of course text content won't provide ordering,
but that will provide more encouragement to use CPIM. 

> thoughts on that, and welcome comments from others.

Given a choice between SIP and something that is "almost-SIP" or an "extended-subset-of-SIP", I would choose SIP. If its not going to be SIP, then lets have something that
does exactly what it needs to do in the simplest possible way.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Jul 2002 17:44:21 -0400

Paul Kyzivat wrote:

> I'm unconfortable with using "dialog ID" without there being a dialog. I
> can't at the moment give a solid reason why this is wrong, but it feels
> like an abuse.

OK, let me know be very explicit.

Message sessions would be a sequence of pages. As per 3261, each of 
those will have a call-id, a from tag, and no to tag. The 200 OK 
response to each of those has a to tag filled in, different for each 
message. The CSeq refers to the sequencing within the URI seen by the 
UAS, as I have indicated in a previous mail, so I have fully backed off 
that notion.

So, there is a dialog ID, but its different for each message, as it 
would be for page mode.

> If we continue the analogy with RTP streams, then this seems like a bad
> assumption. In the case of RTP, we never assume that all the packets
> arrive from the same source.
> This can be violated in many cases, such as when transferring a call,
> where one sender is replaced by another, but the receiver remains
> invariant.

Yes, thats a good point. Its the combination of SSRC and port which 
define a sequence number space. In that case, we would need to do a 
similar thing.

> 
> Why can't we rely on the message content to provide ordering, and the
> reliablility of the transport to guarantee delivery? Of course text
> content won't provide ordering,

Sequencing is an existing sip functionality; it hardly seems worth it to 
use content provided ordering when the transport can already do it.

-Jonathan R.

---

From: Sean Olson <[email-masked]>
Date: Tue, 23 Jul 2002 15:11:43 -0700 (PDT)

> So, there is a dialog ID, but its different for each

If the dialog ID is different for each page, then
how would the CSeq be used across these pages to
do sequencing? Wouldn't there necessarily be a
unique numbering space for each dialog ID? And if
there is a possibility that these pages come from
different sources, then we can't count on CSeq 
ordering. I think I may be misunderstanding your
proposal.

/sean

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com