Subject: [Sipping] Re: [Sip] Question on IM calls.

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Feb 2005 19:48:48 -0500

Moving to sipping...

Dean Willis wrote:
> On Feb 14, 2005, at 12:48 PM, Shetty, Sathish wrote:
> 
>> 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
>>
>>
> 
> 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 . . .

Good plan.

> 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?"

You don't. Invite isn't specified to allow that.

And there is no need. If that is really what you want to do (unlikely), 
you can achieve the same effect by sending an offer that contains no 
media lines. When you do that, the answer can't either, and you end up 
with a session with no media.

> 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.

All this struggle for no reason. Give it up.

> 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.

If you are contemplating enough of a discussion to justify establishing 
a session, then it is enough that you shouldn't be using page mode.

Just start implementing MSRP now.

On the other hand, if what you want is to interoperate with MS, then 
just do whatever they do.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP