Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 29 Jul 2001 23:14:06 -0400

Paul,

Some excellent questions. I believe that, in general, until we are at the
point where the answer is "you do X the same way for messaging as for
voice", we still have more work to do.

So, I had thought about the SDP usage some more since the draft was
released, and think I may have an even better way. Really, the URL
represents an address, and so it belongs in a c line. Its not of type IP4,
but rather a new address space, of type URL. In that case, the SDP might
look like:

m=message 5060 sip message/cpim text/plain text/html
c=IN URL sip:[email-masked]

This indicates that the media type message can be received at the URL
address sip:[email-masked], and that the transport is sip, with allowed
formats message/cpim, text/plain and text/html. I think this is pretty
consistent with the meaning of these paramteres in SDP, and it even allows
us to apply SDP negotiation to the selection of message content types.

So, based on that:

1. to disable a stream, the port is set to zero, as it is for all media
types
2. to hold a stream, you can set the address in the c line to IN IP4
0.0.0.0, but the preferred means is a=sendonly, as it is for other media
types.
3. oneway sessions use a=recvonly or a=sendonly as for other media types
4. it becomes clear on how other transports might work. For example, to use
"foo" as an alternate transport:

m=message 334 foo message/cpim text/plain text/html
c=IN URL foo:[email-masked]

very simple.

I prefer this approach to what is currently documented in
draft-ietf-simple-im-sdp. 

Comments?

-Jonathan R.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, July 20, 2001 4:44 PM
> To: [email-masked]
> Cc: @cisco.com; ";"@cisco.com; [email-masked]
> Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt
> 
> 
> This is a great improvement to the SIMPLE stuff, because it begins
> redraw the line between session initiation and media that was muddled
> with the addition of MESSAGE to SIP. There clearly needs to 
> be a way to
> negotiate text messaging as one medium of a SIP call, and 
> this provides
> that.
> 
> I have a few questions/comments:
> 
> - how does one negotiate a oneway session? Presumably if alice wants 
>   to receive but not sent, she can send the following in an invite:
> 
>       m=message 5060 sip sip:alice@alicepc
>       a=recvonly
> 
>   but what does bob send in return? perhaps something like:
> 
>       m=message ??? sip ???
>       a=sendonly
> 
>   And whatever this is, does it also work in an invite if the person
>   inviting wants to be sendonly? 
> 
>   (I believe comedia used port 9 to indicate a sink. I suppose that
>   could be adopted here - perhaps:
> 
>       m=message 9 sip
>       a=sendonly
> 
>   but I don't find the use of the magic number 9 very appealing.)
> 
>   Similarly, what do I do to refuse the media stream?
>   Do I still use port zero for this purpose, even though the port
>   in this m= line is gratuitous?
> 
> - does there need to be any notion of HOLD in the sense that is
>   used for voice? To go on hold, should I send a reinvite with
>   c=0.0.0.0 even though the c= line is irrelevant here? Or should
>   I reinvite as sendonly? (The general case of this has been
>   discussed elsewhere. I favor a=sendonly as the media independent
>   way to go on hold, with the c=0 being an optional step for media
>   where it makes sense.)
> 
> - section 4 forbids no-SDP invites, using the excuse that the
>   UAS will not know to offer the message medium. This shows a strong
>   voice bias. If you don't offer media in an invite, you ought to 
>   expect the UAS to offer whatever it thinks appropriate, which
>   could be any medium if you haven't expressed any preference. 
> 
>   If I don't want to specify any specific media values, but I do 
>   want to indicate what I might be interested in using, then
>   callerprefs provides a way to do that: I can include a media=
>   parameter to the Contact header in my INVITE.
> 
> - in draft-ietf-simple-im-sdp-00 there is mention of the possibility
>   of other transports than sip. That is fine as far as the SDP
>   syntax goes. But how would that work in practice with SIP? 
>   Unlike codecs, I can't offer multiple transports with the same
>   m= line. So it is difficult to see how I might negotiate which
>   transport a pair of UAs might wish to use to exchange messages.
> 
> 	Thanks,
> 	Paul Kyzivat
> 	Cisco Systems
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

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

---

From: Ben Campbell <[email-masked]>
Date: Sun, 29 Jul 2001 22:40:26 -0500

I agree that a URL in the c-line would be a better approach, and we even 
added it in the open issue section in the im-sdp draft.  I am uncertain, 
though, that this is permissible, as the SDP definition explicitly says 
IPv4 address (in the descriptive text section. The BNF actually says 
(IP4|IP6)) for that field. It seems pretty clear the authors intended 
that as a network address, not a URI. (in contrast to the m-line 
definition, which specifically describes how to extend it.)

So, if we do that, is it still SDP? Can we make that change without 
updating the SDP RFC? I can see extended it to other network address 
types, but extending to URIs seems like a change in philosophy.

Again, I think it would be a good extension if we can do it.

---

From: Vasilis Polychronidis <[email-masked]>
Date: Mon, 30 Jul 2001 02:55:50 -0700

> draft-ietf-simple-im-sdp.

I like it too it is closer to the VoIP model.
One small question:
In your above example (SDP) how do you distinguish
between sip/tcp or sip/udp?
or more general foo/tcp, foo/udp, foo/sctp, etc. ?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jul 2001 15:29:25 -0400

I think the proposed revisions are a good improvement.
Comments below.

	Paul

> voice", we still have more work to do.

Yes, I think so too. But some of that work probably has to be done on
voice rather than on messaging.

> but rather a new address space, of type URL.

This does seem like the right way to go, if it is deemed valid SDP.
Are there SDP gods who must bless this usage?

> In that case, the SDP might look like:
> 

In this example, you have put the sip port in the m= line, but not in
the url in the c= line. Its not clear what you would do if the port was
not the default. Would you put it both places?

 m=message 5061 sip message/cpim text/plain text/html
 c=IN URL sip:[email-masked]:5061

or would you only put it in the m= line?

I hate it when the same value *must* appear in two places. That always
opens up the question of what happens when it doesn't. But I also hate
the idea of removing data from the url that has to be put back to use
it. To me the preferred solution would be to omit the port from the m=
line. The m= syntax is too rtp or udp centric, and there ought to be
provision for omitting a field when it isn't relevant. Perhaps simply
permitting a "*" as a placeholder.

> 1. to disable a stream, the port is set to zero, as it is for all media

ok

> 0.0.0.0, but the preferred means is a=sendonly, as it is for other media

ok. But in that case it should be specified how all the irrelevant
fields should be filled in. In particular, with a=sendonly, what should
be in the port field of the m=?