Subject: [Sip] Question on IM calls.

From: "Shetty, Sathish" <[email-masked]>
Date: Mon, 14 Feb 2005 10:48:42 -0800

Hi,

   We are currently working on SIP Instant messaging. Our goal is to design
a client to support only IM calls using MESSAGE method. I'm just wondering
how to format the IM only SDP message in the INVITE/200 OK message. In case
of IM calls most of the parameters in the SDP are NOT required ( such as
codec, RTP/RTCP port etc)  but RFC 2327 mandates all the parameters. I saw
MSRP proposal for this using SEND method. Is there any other proposals in
conjunction with MESSAGE method for IM only calls?

Is there any RFC or drafts other than
http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-09.tx
t

Please advice..

Thanks,
Sathish.

_______________________________________________
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: Mon, 14 Feb 2005 14:17:55 -0500

Shetty, Sathish wrote:
> how to format the IM only SDP message in the INVITE/200 OK message.

Are you developoing an independent system, or a system intended to 
interwork with some other system that already works this way? (E.g. 
Microsoft.)

> In case

The problem you are running up against is that MESSAGE was not designed 
to support IM *calls*. There has been an attempt to draw a distinction 
between "page mode" (using MESSAGE) and "session mode" (e.g. using MSRP.)

There is (I'm pretty sure, though I don't remember exactly where) an 
explicit prohibition against using MESSAGE for session oriented 
conversations. So you should not be using INVITE to establish a session 
in which MESSAGE will be the way of exchanging IM "media".

> http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-09.tx

There were a number of drafts exploring various possibilities before 
settling on MSRP. But they have all long since expired.

Other than that, there is what Microsoft is currently doing, which is 
not sanctioned by the IETF. If you want to do what they do, you either 
need to get details from them, or reverse engineer their product.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Feb 2005 18:25:32 -0600

> http://www.ietf.org/internet-drafts/draft-ietf-simple-message- 

Note that this is probably a question best left to the sip-implementors  
list, but it does raise a protocol usage question that might should  
have been on the SIPPING list, so if we need to debate this at any  
length we should move it there (or off-line).

There's probably something wrong at the religion level with what I'm  
about to propose, so I've just donned my asbestos undergarment . . .

It seems reasonable to me to have a null offer-answer -- that is, no  
SDP in the INVITE, none in the 200 OK, and none in the ACK, since  
you're not establishing a media channel in the context of this dialog.

The obvious problem is "How do you know to do this?"

For example, one might send an INVITE from such a client to another  
client that supports voice as well as null-media sessions. This UAS  
might respond with an SDP offer in the 200 OK, making life complicated.

One answer might be that the set of AoRs used for the application is  
restricted, so you just know it isn't going to happen. This might work  
adequately for a lab exercise, a student project, or something like  
that. But eventually, you're going to want to go live on the Internet  
and talk to strangers (and their user agents).

The caller-preferences/callee-caps mechanisms give us a framework for  
capability negotiations. So we could define a media feature tag  
(perhaps "nomedia") which the caller could include in the INVITE  
(perhaps with the require" modifier), indicating the the caller does  
not wish to engage in a media offer-answer.

Another, (perhaps more theologically correct) approach would be just to  
send the MESSAGE request to the target AoR, and forget about  
establishing a surrounding dialog-context using INVITE. After all, for  
most uses of pager-mode messaging, the dialog is just overhead you  
didn't really need anyhow.

--
Dean