David Stuart wrote: [snip]
I am wondering about a situation which does not seem to be outlined here. Let's say I have two users, which are having a "conversation" using pager mode IMs. Let's call them A and B.
A sends an IM to B, a new Call-ID is created, CSeq is set to one.
There is no reason for a Call-ID here, because this message isn't being sent within an existing dialog and isn't establishing a new one.
A sends another IM to B, in the same "conversation".
The human users may think they are in a "conversation", and the IM applications they are using may each think they are in a "conversation", but as far as SIMPLE is concerned, pager mode IMs aren't part of a "conversation". If they were, then that would be considered an "IM session", which would call for session mode IM.
This was part of a compromise, because using the sip signaling channel to carry IM conversations is considered evil - with possibility to harm the signaling infrastructure.
Question: do we use the same Call-ID here and increment the CSeq (even though we did not create a dialog)?
No.
I would think this is a bit like being in the same Call but not the same Dialog (since no dialog was created).
There is no such notion.
B sends an IM to A
Question: should B use the same Call-ID (the same call) as A, even though no dialog was created?
No.
IMs in general are a source of much confusion during SIP integration. If anyone could help out, I'd appreciate it.
The work on session mode IM is creeping toward completion. Beyond that, there is some appreciation that added work is required to specify how all this machinery is put together to create a complete IM "system". Your questions go to that unresolved issue.
For instance, in your example:
- when A sends the first message, it could be sent via page mode because it isn't known whether B will answer, and page mode is easier.
- Or it could be done using session mode, by sending an INVITE offering MSRP. B's application could be set to auto-answer invites with MSRP. Then A's application sends the first message within the MSRP session.
- Or it could be done using session mode as above, but B's application might not answer automatically. Instead, it could respond with a 180 that establishes an early dialog. Then A's application could send the first message. But it wouldn't permit A to send another message within the conversation until the invite is answered. B's application would display the first message, but not answer until B has entered a response. Then it would both send the response and answer the call.
- If A had sent the first message with MESSAGE, when B goes to answer might be a good time to negotiate session mode. But there are issues in getting the session established to the proper UA for A.
These questions aren't yet resolved. In fact they haven't yet been formally asked.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
