Subject: RE: [Sip] SIP session without SDP

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 7 Oct 2005 19:56:00 +0200

Hi,

>>>There are dialogs, and there are things that use dialogs: 
>>>invites and subscriptions. The dialog itself has a certain amount of state 
>>>associated with it. Then each usage has some added state. So, 
>>>a dialog has: route set, target address, callid, local and 
>>>remote CSeq, ...
>>True. But, all of this is "maintained" using SIP headers/parameters. You don't need SDP for that.
>> 
>> 
>>>An invite dialog usage has very little state of its own. I think you can 
>>>probably consider offer/answer state to be part of this, maybe the most 
>>>recent offered and answered sdp.
>> 
>>True. But, offer/answer state is needed only when you DO use SDP.
> 
>No. offer/answer state is needed when you exchange offers and 
>answers, whether you use SDP, SDPng, or something else yet to be invented.

[CHH] True. But, that you do in order to "synchronize" the media. The only SIP signalling specific related to offer/answer is that you can't have two outstanding re-INVITEs, but even that you can achieve without an offer/answer state machine (all you need to know is that you have an ongoing re-INVITE transaction).

>The primary *purpose* of the INVITE is to initiate the exchange of offers and answers. I believe it is required to do so.

[CHH] I think the primary purpose of the INVITE is to initiate the session - which in most cases also includes initiating the exchange of offers and answers.

>If you don't need the state of the invite dialog usage, then you don't 
>need the INVITE. That was my point in bringing up dialog usages. If all 
>you want to do is exchange MESSAGEs within a dialog, then you should 
>create some new way to establish a message-dialog-usage.

[CHH] Of course that can be done, but I thought using INVITE would be an easier solution... :)

Regards,

Christer

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Oct 2005 14:21:45 -0400

> [CHH] True. But, that you do in order to "synchronize" the media. The only SIP signalling specific related to offer/answer is that you can't have two outstanding re-INVITEs, but even that you can a…

You also cannot have two outstanding offers. E.g. you cannot send an 
INVITE with an offer, and then follow it with an UPDATE containing 
another offer before receiving an answer.

I don't think we need to get into the details of what state is required 
to implement the protocol correctly. It is sufficient to say that there 
is *some* state that is required because of INVITE and offer/answer. And 
this is specific to INVITE, over and above the state required for 
dialogs in general.

> [CHH] I think the primary purpose of the INVITE is to initiate the session - which in most cases also includes initiating the exchange of offers and answers.

I discussed this further in an earlier message.

> [CHH] Of course that can be done, but I thought using INVITE would be an easier solution... :)

I don't think it is "easier" to change the defintion of INVITE in a way 
that will probably break many/most UA implementations, in order to 
support doing something that probably shouldn't be done.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 07 Oct 2005 18:45:34 -0400

Hmmm... I get the feeling that there are a lot of loose ends in this
discussion, and different people are grabbing different loose ends,
which is confusing the discussion.  Let me try to enumerate what seem to
me to be the essential factors.

It may be that when INVITE was defined, nobody envisioned that it might
be used to establish a dialog that did not have a "media
session" (described by SDP or something similar).  But there seems to be
nothing in the standards to prevent someone from doing so, nor any
reason that proxies or other infrastructure agents would fail to process
them correctly.

There is no currently known purpose for which such a session-less
dialog is better than other existing mechanisms.  (In particular,
applications should avoid sending streams of requests, to avoid
overloading proxies.)

Trying to establish such a dialog with a current UA will probably fail.
(But that is of no consequence, as no current UA intends to use such
dialogs.)

There is the concept of "dialog usages", which doesn't seem to have been
discussed much in recent times, or mentioned in the RFCs, but it is a
useful concept for discussing particular subsets of the functioning of a
dialog.  Currently, there is "invite usage" (embracing media
negotiation), and "subscribe usage" (embracing a subscription and its
notices).  A dialog can contain several usages simultaneously.  E.g., a
REFER in an INVITE-initiated dialog creates a subscribe usage, or a
SUBSCRIBE-initiated dialog can have several further SUBSCRIBEs sent
within it, so the dialog contains several subscribe usages.  Some
operations can affect multiple aspects of a dialog -- for instance, a
re-INVITE can change the media session of the invite usage, but also
change the target address, which affects all usages (as well as outside-
of-usage within-dialog requests like OPTIONS).

Nonetheless, there are ways that INVITE-initiated dialogs differ
substantially from other dialogs that is not a consequence of usages --
INVITE operates in a way consonant with human attention, generating
(with assistance from proxies) only one dialog (despite forking), and
tolerating long dialog set-up times.  Other requests that initiate
dialogs are expected to complete quickly and proxies allow them to
initiate multiple dialogs.  These features may be orthogonal to the uses
to which dialogs are put once they are established, which would suggest
decoupling the usages within a dialog from the type of request
(INVITE/non-INVITE) used to create it.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Oct 2005 19:13:52 -0400

Dale,

I was agreeing with your summary until the very end. See comment down 
there. I'm changing the subject line because we have gotten off the 
original subject.

	Paul

> substantially from other dialogs that is not a consequence of usages --

This is not true. It is only the invite-dialog-usage that differs from 
other kinds of dialog-usages. It is the usage that has the alerting 
associated with it, not the dialog.

> (with assistance from proxies) only one dialog (despite forking), and

If there is forking, then one INVITE can generate multiple dialogs. 
Usually most of them are just early dialogs, but that needn't be the 
case. And forking of SUBSCRIBE can also result in multiple dialogs.

> (INVITE/non-INVITE) used to create it.

Most of the time, when speaking (loosely) about a dialog, people are 
really talking about a combination of a dialog-usage plus the 
corresponding dialog.

There are a bunch of weird things that are possible, but that nobody 
ever tries, that would make all these distinctions clearer. E.g.

- establish a dialog with SUBSCRIBE, then send an INVITE within it

- establish a dialog with INVITE, then send a SUBSCRIBE within it.
   Then send BYE for the INVITE but keep the subscription active,
   hence keeping the dialog alive. Then, send another INVITE within
   the dialog.

- send an INVITE that parallel forks. Receive 180 from both forks,
   and PRACK both of them. Then send a SUBSCRIBE (perhaps to the
   dialog event package) in each dialog. When one of them answers
   with a 200, the proxy will cancel the other INVITE. You will
   then have one dialog with an INVITE and a SUBSCRIBE, and another
   dialog with just a SUBSCRIBE.

Most of these implications were apparently missed when 3261 was put 
together. The authors hate it, and there are efforts to deprecate the 
shared use of dialogs. Personally, I think it never should have been 
there, but the cat is out of the bag, and there is no way of getting it 
back in the bag.

OTOH, if you try these corner cases, I will be surprised if you very 
often get success. It certainly isn't something people are likely to 
test for. But it is still useful to understand what the model is.

I am aware of people who have established subscriptions to the same 
event package in both directions over the same dialog. (And it didn't 
work the first time they tried.)

	Paul

---

From: Dean Willis <[email-masked]>
Date: Sat, 08 Oct 2005 12:54:47 -0500

> - establish a dialog with SUBSCRIBE, then send an INVITE within it

Oddly enough, I never thought of this before.

And I'm NOT recommending it now.

But here's something to think about:

In OMA's PoC architecture, some mobile UAs have long-lived relationships 
with network UAs called "Participating Functions", (PF). In the current 
spec, the mobile UA at start time sends an INVITE to its PF and 
establishes a dialog. This dialog is basically used like a conference 
call. When the mobile UA wants to talk to somebody else, the mobile UA 
sends a REFER within that dialog to the PF, with the Refer-To: pointing 
at the target, and the PF then generates an INVITE to the target. For 
calls in the other direction, the PF gets the INVITE and informs the 
mobile UA of the new call via a conference-package-like NOTIFY, 
generally accepting the INVITE after the mobile UA sends 200 for the 
NOTIFY (but sometimes not -- in the interest of performance tweaking, it 
can respond speculatively and send an "unconfirmed indication").

Why all the trickiness? This gives us an in-network high-bandwidth point 
that can manage (and serialize) concurrent flows to the mobile, so that 
the mobile's tiny-little-capillary bandwidth doesn't get logjammed. It 
also lets us fake-out some of the user-experience of latency that might 
otherwise occur. The PF acts as a signaling-and-media B2BUA to gain this 
control. It also keeps us from having to send media descriptions 
over-the-air for every call (ostensibly saving tons of bandwidth) -- the 
long-lived INVITE negotiates the offer-answer options for all later 
calls on that side.

But I'm starting to speculate how this might look if the long-lived 
dialog were established via a SUBSCRIBE (perhaps to a new event package) 
and calls were set up by sending INVITE within that dialog, instead of 
REFER. Hmmm.

--
Dean

---

From: "Dale R. Worley" <[email-masked]>
Date: Sat, 08 Oct 2005 15:21:55 -0400

> case. And forking of SUBSCRIBE can also result in multiple dialogs.

True, the difference is not absolute.  But in an INVITE situation, the
proxies attempt to prevent the establishment of more than one confirmed
dialog, whereas in a SUBSCRIBE situation, they are forbidden from trying
to prune the set of dialogs.  In various cases, this makes various sorts
of difference.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 08 Oct 2005 19:17:08 -0400

Dale R. Worley wrote:
> to prune the set of dialogs. 

They are? That is news to me. Where is that specified?

> In various cases, this makes various sorts
> of difference.

I think there is less difference than people think.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 19 Oct 2005 23:15:54 -0400

> and calls were set up by sending INVITE within that dialog, instead of 

I can see the attraction, but I'm not sure you'd save much.  By the
offer-answer model and all the machinery, you could still have only one
INVITE dialog-usage within the dialog at a time.  Using INVITEs would
allow you to periodically re-negotiate the media, but they would also
*require* you to re-negotiate the media every time you made a call.
(And you've noted that your lords and masters think that's a Bad Idea.)

How about ox and ass in double harness?  Continue to use REFER to
redirect the ultimate endpoint of the call, but use re-INVITE (in the
future) when the phone and/or its base station decides it needs to re-
negotiate the media.  That would actually make sense for a phone that
transitions between 3G and WiFi usage, and even more so once WiMax
becomes popular.

Dale

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Oct 2005 00:55:00 -0500

> transitions between 3G and WiFi usage, and even more so once WiMax

Makes sense to me. More sense than my crazy idea, anyhow.

Thanks, Dale.

--
Dean