Subject: RE: [Simple] IM: A session or not

From: Robert Sparks <[email-masked]>
Date: Thu, 10 May 2001 11:08:42 -0400

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2001 11:30 AM
<snip>
> The chat stream is signaled in SDP. A 
> chat session is
> nothing more than a series of pages, which share a common Call-iD (to
> indicate that pages are part of the same stream, similar to 
> the usage of the
> port number in RTP), and a common CSeq numbering (to provide 
> sequencing,
> like the SN in RTP), both of which have unidirectional 
> semantics only. What
> I mean by this is that the UAC, in its invite, indicates the 
> call-id it
> would like to see for incoming pages for this stream, and the 
> UAS, in the
> 200 OK, indicate the Call-ID it would like to see. CSeq 
> provides ordering as
> always. I see no need for the message stream call-id to be 
> the same as the
> call-id for the SIP INVITE/BYE wrapping the session. In fact, 
> I can think of
> some compelling third party call control applications where 
> they can't be
> the same. I think this is in line with what Sean was arguing for.

This answers "How much of the call-leg identifier used by the
chat session itself do you signal with the INVITE" very nicely.

Sean - at one point you were arguing 
>>From: Sean Olson (EUS) [mailto:[email-masked]]
>>Sent: Wednesday, May 02, 2001 5:48 PM
>>
>>Third, SDP allows multiple media streams. Are we going to 
>>allow (in the general case) multiple signalling streams? 
>>If so, Call-ID is definitely out. But there are more interesting 
>>questions raised by this possibility. 

Jonathan is proposing using Call-ID to demux each of those streams.
Does the problem you were seeing still apply?

<more snip> 

> There is no record-routing, since pages have no session semantics, and
> therefore, record-routing doesn't make sense. I don't want to 
> define two
> separate proxy behaviors for MESSAGE - one for pages, and the 
> other for chat
> streams that are routed through proxies. This will be a huge pain. 

So, we assume that if the first message in a stream can get to
its destination any subsequent will as well, and don't care if
it takes the same path each time (beyond what we know before the
first message is sent and include as preloaded Route headers in 
the contact SIP URL in the SDP). If the conversation forks in
one direction, it will _stay_ forked through the whole conversation.

RjS

---

From: [email-masked]
Date: Thu, 10 May 2001 10:22:44 -0500

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> 

I'm happy with this solution (including the use of URIs in SDP).

/a