Subject: [Simple] Comments on MSRP

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 12 May 2004 08:25:26 +0200

Hi,

Some comments on the MSRP (-05) spec. Some of my questions may be related to relays. However, I don't think they are related to the relay functionality (which will be defined later) itself, but more to the rules on how messages are built by the end nodes etc.

I have just recently started to look into it, so I appologise if some issues have been discussed before (I thought it may be a good idea to send these before the interim meeting, IF some of them are valid, so I didn't have time to check old posts).

Message size
------------

The draft says that there are no restrictions on the message size. That is of course true from a transport point of view, but clients may still have limitations on how big messages they are able to receive (note that I am talking about the TOTAL size of the message, not fragmentations).

I think it would be useful if clients could indicate the maximum payload size he is able to send and receive, either per type or stream.

If the max size is dependent on the media type, max size could be defined as a accept-type token paramter:

example:

accept-type: X;max-send=1000;max-receive=1000, Y;max-send=2000;max-receive=500

And, if the message size it not type dependent, generic max size attributes could be used.

example:

a=max-send: 1000
a=max-receive:1000

Even if one is not going to send more than the other party indicates he is able to receive I still think it is important that a node can indicate how much he is able to send. For example, the remote node may reserve memory according to that information, and/or intermediate proxies may do forking/routing based on the client capabilities.

An MSRP "message size too big" error code could also be useful, if a node for whatever reason is not able to accept a SEND message. This may be due to that the remote node is sending more data than was agreed in the offer/answer, but also due to that the receiving node for a short period isn't able to receive the agreed data size (if the max size change is permanent a new offer should of course be sent, instead of sending an error reply to every SEND).

Port zero
-------------

Q1:

The spec says that "port zero has the standard SDP meaning". However, the spec does not say how port zero applies to MSRP. Ie IF one sets the port to zero (to remove the stream), how does that affect the TCP connection? Will the TCP connection be released? WHO will release the TCP connection? The draft only talks about tearing down connections when the whole session is terminated, which is not the case if a single stream is removed.

Q2:

I assume it's not allowed to set the URL port value to zero (it has not the same meaning as an SDP zero value), so maybe it should be mentioned.

Path attribute (chapter 6.4 and 6.5)
------------------------------------

Q1:

As we know, the SDP ABNF rules are often more strict than the generic ABNF rules, so I wonder if it's allowed to, instead of having multiple URLs in a single a=path attribute, have multiple a=path attributes (compare to Route, Record-Route and Via in SIP). It is allowed from an ABNF point of view, but what about from an SDP point of view?

example:

a=path: x y z

or

a=path: x
a=path: y
a=path: z

If multiple path attributes are NOT allowed (SDP basically says that the ordering of attributes have no meaning, so I guess that multiple path attributes should not be allowed) I think it should be clearly written.

Q2:

Assume A sends the initial offer to B, and multiple path attribute URLs are added by relays. Now, if at some point B sends a new offer to A (no matter if the actual MRSP info has changed or not), does that affect the order of the URLs (comapre to Route, Record-Route and Via in SIP, where the order is depending on from whom the request is sent)?

example:

A->B Offer

a=path:x y

B->A Offer

a=path: y x

or

a=path: x y

Updated SDP offers (chapter 6.6)
--------------------------------

The chapter does not say anything about the case when the SDP, especially the MSRP m= line, IS updated. Which SDP parameters/attributes are allowed to be updated? Eg, if a new top path attribute is provided, what will happend to the previous TCP connection? Will it be released? Who will release it?

SDP mode attributes
-------------------

Do we need to say something about the mode atttibutes (sendrecv, inactive, etc)? For example, I guess one can not offer a sendonly session, since the receiver is supposed to send VISIT. And, even if one receives a MSRP request on a recvonly connection he will still send a response to that request (I guess he will not initicate requests himself, though).

Forking
-------

Do we need some text about forking? Because, since it is allowed to start sending MSRP messages before 200 is sent it may happend. For example, different path attribute values will be received from different legs, and different MSRP header values will be used in messages received from different legs?

I can't currently think of any major problems that forking would cause, and I am not sure it's really within the scope of the draft, but maybe it's at least something we should think about.

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple