Subject: [Simple] Message session & associated dialog

From: Peter Päppinghaus <[email-masked]>
Date: Fri, 12 Jul 2002 11:12:45 +0200

Hi,

so far I have not been following the discussions about message sessions, 
so maybe I am cooking up something that was discussed already.

Message sessions are somewhat hybrid in nature: on the one hand they are 
not part of the dialog that initiated the message session, on the other 
hand they are associated with this dialog. I think it would be helpful 
if this association relation is reflected somehow in the MESSAGE 
requests sent in a message session.

draft-rosenberg-simple-message-session-00 is silent about construction 
of Call-ID and From and To header tags in the MESSAGE requests sent 
within a message session.

Following RFC 3261 the MESSAGE requests should receive Call-IDs 
different from the Call-ID of the associated dialog. This is necessary 
in order not to mess up the CSeq numbering.
But it seems reasonable to me that they would share the From and To tag 
values with the From and To tag values of the associated dialog.

If one would introduce a new informational header, say "Assoc-Call-ID" 
carrying the value of the Call-ID of the associated dialog, then it 
would be possible to reconstruct the dialog ID of the associated dialog 
from the MESSAGE requests in the message session. I think this would be 
very useful.

-- 
Dr. Peter Päppinghaus
Siemens AG            | Phone:    +49 89 - 722 40065
ICM N PG U ID A1      | Fax:      +49 89 - 722 58726
Hofmannstr. 51        | Visitors: Building 1702 / Room 530
D - 81359 München     | Email:    [email-masked]

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 13 Jul 2002 09:22:32 -0400

inline.

> requests sent in a message session.

Well, they are associated just like an RTP stream is associated with the 
dialog that sets it up. In the case of RTP, the association occurs 
through the port numbers handed out in the SDP. For MESSAGE, the idea is 
that its the request URI. So, in an INVITE, the sdp would be like:

c=IN IP4 host.example.com
t=0 0
m=message 54344 SIP
a=user:ahss7aa9

which would result in receiving IMs that look like, in part:

MESSAGE sip:[email-masked] SIP/2.0

the request URI is used for the demux, as a result.

> within a message session.

Well, the draft was just a proposal.

I guess the messages would all use the same dialog ID, with increasing 
CSeq within the dialog. Different dialog ID than the INVITE one, of course.

> in order not to mess up the CSeq numbering.

Right.

> values with the From and To tag values of the associated dialog.

I don't see any need for that; see above.

> from the MESSAGE requests in the message session. I think this would be 

Why?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jul 2002 09:27:07 -0400

> CSeq within the dialog. Different dialog ID than the INVITE one, of course.

It makes sense that all the messages share a dialog. The question is: what causes this dialog to be established?

There are currently two ways of establishing a dialog:

- the 2xx reply to an INVITE can establish one

- the 2xx reply to a SUBSCRIBE can establish one

In the case we are discussing, MESSAGE requests are the only thing being sent along the path where we want a dialog. But we don't want the response to every MESSAGE request
to establish a dialog. Some possibilities:

- send a medialess INVITE to establish a dialog, and then send the MESSAGEs within that dialog.

- permit the recipient of a MESSAGE to decide contextually whether to establish a dialog. (Would require some rules to prevent doing so when all the flow control
constraints haven't been met.)

Sending another INVITE is straightforward, but seems a bit circuitous and wasteful of round trips. But using the MESSAGE to do this may lead to a blurring of the
distinction between page and session mode messaging.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Jul 2002 19:36:54 -0500

> distinction between page and session mode messaging.

That blurring concerns me a lot. A method where a successful request 
sometimes creates a dialog, and sometimes does not, is problematic. In 
particular, letting the recipient select whether a session is created 
may ignore the wishes of the sender.

In particular, I can imagine a client might exist that supports page 
mode, but not session mode. If I send you a MESSAGE request with such a 
client, and you add a contact header to your response with the 
assumption that it will create a dialog, what happens? You think we are 
in a dialog, but I think we are not.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jul 2002 21:21:14 -0400

Ben - I agree with you. But I can't tell if you:

- believe jonathan's proposal already implies 
  use of invite to establish the dialog

- think invite ought to be used

- have some other way in mind to set up the dialog

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Jul 2002 00:57:45 -0500

> - have some other way in mind to set up the dialog

If by Jonathan's proposal you mean 
draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jul 2002 10:18:35 -0400

below...

> draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE.

Yes, that is the one. I guess I wasn't clear about my concern. Here is the call flow from draft-rosenberg-simple-message-session-00:

       Caller               Proxy               Relay              Callee
          |(1) INVITE         |                   |                   |
          |m=54344            |                   |                   |
          |c=1.2.3.4          |                   |                   |
          |------------------>|(2) INVITE         |                   |
          |                   |m=54344            |                   |
          |                   |c=1.2.3.4          |                   |
          |                   |hop=sip:relay      |                   |
          |                   |-------------------------------------->|
          |                   |(3) 200 OK         |                   |
          |                   |m=44345            |                   |
          |                   |c=4.3.2.1          |                   |
          |(4) 200 OK         |<--------------------------------------|
          |m=44345            |                   |                   |
          |c=4.3.2.1          |                   |                   |
          |hop=sip:relay      |                   |                   |
          |<------------------|                   |                   |
          |(5) ACK            |                   |                   |
          |---------------------------------------------------------->|
          |                   |                   |(6) MESSAGE        |
          |                   |                   |ruri=1.2.3.4:54344 |
          |                   |                   |Route=sip:relay    |
          |                   |                   |<------------------|
          |(7) MESSAGE        |                   |                   |
          |ruri=1.2.3.4:54344 |                   |                   |
          |<--------------------------------------|                   |
          |(8) 200 OK         |                   |                   |
          |-------------------------------------->|                   |
          |                   |                   |(9) 200 OK         |
          |                   |                   |------------------>|
          |(10) MESSAGE       |                   |                   |
          |ruri=4.3.2.1:44345 |                   |                   |
          |Route=sip:relay    |                   |                   |
          |-------------------------------------->|                   |
          |                   |                   |(11) MESSAGE       |
          |                   |                   |ruri=4.3.2.1:44345 |
          |                   |                   |------------------>|
          |                   |                   |(12) 200 OK        |
          |                   |                   |<------------------|
          |(13) 200 OK        |                   |                   |
          |<--------------------------------------|                   |
          |(14) BYE           |                   |                   |
          |---------------------------------------------------------->|
          |(15) 200 OK        |                   |                   |
          |<----------------------------------------------------------|

This shows the MESSAGEs that are not part of any dialog. 

Then, earlier in this thread:

> CSeq within the dialog. Different dialog ID than the INVITE one, of course.

This last sentence is what started this discussion. If the messages are to use the same dialog ID, and it is a different dialog ID than the INVITE, then where does this
other dialog come from?

In the above flow, it would have to be implicit in the first MESSAGE (6), which seems wrong.

Another possibility (but also dubious) would be to generate a new INVITE between (5) and (6), from caller to callee, using the route header that involves the relay. This
would be a media-less invite with the sole purpose of establishing a dialog. Then, the messages could be sent within the context of this dialog.

The simplest answer here is just to say that the messages don't share a dialog.

Or, it could be considered like REGISTER, where register refreshes SHOULD be sent using the same callid yet there is no dialog. Session oriented messages could also be sent
using the same callid without any implication that this is a dialog. (But I don't like this much either.)

	Paul

---

From: Peter Päppinghaus <[email-masked]>
Date: Tue, 16 Jul 2002 17:06:37 +0200

Comments inline.

>           |------------------>|(2) INVITE         |                   |

What starts the topic - in my opinion - is simply the observation that 
the messages within a message session are intended to be threaded 
together, and this should be reflected SOMEHOW.

For example, there should be a means to guarantee correct sequencing. 
Unless one thinks about a completely different approach to this - like 
e.g. the one in draft-olson-simple-publish-00 - the most natural 
approach seems to be to let the messages of a message session be 
threaded together by sharing their From tag, To tag and Call-ID values, 
und use CSeq numbering for sequencing.

Since RFC 3261 leaves room for SIP extensions to "define other means for 
creating dialogs", why not stipulate the following: when a response to 
an INVITE creates a message session, it creates at the same time (beyond 
the signaling dialog) a second dialog, namely a media-dialog?

The route of this media-dialog is based on information contained in the 
SDP of the signaling dialog. In the same manner a dialog ID for this 
media-dialog could also be negotiated in the SDP of the signaling 
dialog. Termination of the signaling dialog should imply termination of 
its associated media-dialog. (As far as I understand, RFC 3261 also 
leaves room for that.)

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Jul 2002 17:17:53 -0500

>           |------------------>|(2) INVITE         |                   |

OK, I see. My initial reaction is to just say the messages don't share a 
dialog. I don't think we want to deal with the implications of saying 
they do share a dialog (i.e. record-route, contact headers, etc.)

---

From: Michael Hammer <[email-masked]>
Date: Wed, 17 Jul 2002 11:00:04 -0400

Ben,

If you substitute RTP stream for MESSAGE stream in this discussion are 
there any differences?  That is, is the correlation between the RTP stream 
and the SIP signaling stream any different?  Can we conclude that the 
operational requirements of both these media streams would be parallel?

Mike

At 05:17 PM 7/16/2002 -0500, Ben Campbell wrote:
>>Yes, that is the one. I guess I wasn't clear about my concern. Here is 
>>the call flow from draft-rosenberg-simple-message-session-00:
>>This last sentence is what started this discussion. If the messages are 
>>to use the same dialog ID, and it is a different dialog ID than the 
>>INVITE, then where does this
>>other dialog come from?
>>Another possibility (but also dubious) would be to generate a new INVITE 
>>between (5) and (6), from caller to callee, using the route header that 
>>involves the relay. This
>>would be a media-less invite with the sole purpose of establishing a 
>>dialog. Then, the messages could be sent within the context of this dialog.
>>Or, it could be considered like REGISTER, where register refreshes SHOULD 
>>be sent using the same callid yet there is no dialog. Session oriented 
>>messages could also be sent
>dialog. I don't think we want to deal with the implications of saying they 
>do share a dialog (i.e. record-route, contact headers, etc.)
>
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Jul 2002 19:15:14 -0500

It seems it would make sense for it to be the same. The MESSAGE stream 
should be just another media stream from the perspective of the 
associated dialog.

Michael Hammer wrote:
> there any differences?  That is, is the correlation between the RTP 
> stream and the SIP signaling stream any different?  Can we conclude that 
> the operational requirements of both these media streams would be parallel?
> 
> Mike
> 
> 
>>> Yes, that is the one. I guess I wasn't clear about my concern. Here 
>>> is the call flow from draft-rosenberg-simple-message-session-00:
>>>        Caller               Proxy               Relay              
>>> Callee
>>>           |(1) INVITE         |                   |                   |
>>>           |m=54344            |                   |                   |
>>>           |c=1.2.3.4          |                   |                   |
>>> This last sentence is what started this discussion. If the messages 
>>> are to use the same dialog ID, and it is a different dialog ID than 
>>> the INVITE, then where does this
>>> other dialog come from?
>>> Another possibility (but also dubious) would be to generate a new 
>>> INVITE between (5) and (6), from caller to callee, using the route 
>>> header that involves the relay. This
>>> Or, it could be considered like REGISTER, where register refreshes 
>>> SHOULD be sent using the same callid yet there is no dialog. Session 
>>> oriented messages could also be sent
>> OK, I see. My initial reaction is to just say the messages don't share 
>> a dialog. I don't think we want to deal with the implications of 
>> saying they do share a dialog (i.e. record-route, contact headers, etc.)
>>
>>

---

From: Peter Päppinghaus <[email-masked]>
Date: Thu, 18 Jul 2002 12:09:20 +0200

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

How would sequence numbering be obtained, if the MESSAGE requests of a 
message session stream all have different Call-IDs?

Could not a shared Call-ID play a similar role that an SSRC 
(synchronization source identifier) plays in RTP, and the CSeq header 
field play the role that the sequence number field plays in RTP headers?

Peter

Ben Campbell wrote:

>> stream and the SIP signaling stream any different?  Can we conclude 
>> that the operational requirements of both these media streams would be 
>> parallel?
>>
>> Mike
>>
>>
>>> OK, I see. My initial reaction is to just say the messages don't 
>>> share a dialog. I don't think we want to deal with the implications 
>>> of saying they do share a dialog (i.e. record-route, contact headers, 
>>> etc.)
>>>
>>>