Flemming (and other modem experts),

Sorry for the delay in responding to this. Been real busy.

On 07/12/2002, at 10:21:09 A.M., you wrote, in part:

...

It's really unambiguous (Assuming ya got all the commas right! :-) ),

...

and pretty compact and concise.

All true, but as you note, you'd better not get those commans wrong. It's fairly error prone and not very easy to debug.

Since the SDP is generated and parsed by computers, not humans, getting the commas right is no better or worse than, e.g., getting the spelling of attribute names right. IMHO, not a problem either way, nor is it all that hard to debug either.

...

On the issue of SIP/SDP transaction size. yah, we're probably OK for

now.

...

But the way and rate things are being added I'm just afraid we're gonna be in trouble soon.

What kind of trouble ? SIP allows you to use TCP (or SCTP for that

matter), so

if UDP fragmentation is your concern, you already have a solution. Also

note,

that SIP allows you to use compression to reduce the size of messages,

and

clearly, text is fairly compressible.

I have several concerns with using either TCP or SCTP rather than UDP here, or with doing anything that might directly or indirectly require the use of TCP or SCTP:

1. As you correctly state, TCP and SCTP are allowed by SIP, while UDP is required. But the result of this is that some endpoints and proxies only implement UDP, and not TCP or SCTP. If TCP or SCTP were required for sessions including MoIP (or the only real alternatives available because of, e.g., transaction sizes), then those endpoints and proxies would have to: - implement TCP or SCTP in order to make their MoIP implementations most useful; or - not implement MoIP. I would prefer to not have to force implementers to make that choice. We can do that by making sure that MoIP works well with UDP.

2. Even if TCP or SCTP were (almost?) required, which one do ya use? Some implementers may choose one, others the other. Again, interopera- bility problems. IMHO, better to stay with one (UDP) that everyone can and does use.

3. For proxies that support thousands or tens of thousands of endpoints simultaneously, it is impractical for them to: - have a TCP connection open to each of them simultaneously, because of resource consumption; and - NOT have a TCP connection open to each of them simultaneously, because of the latency in opening a TCP connection. SCTP has the same problems. Again, the best solution is UDP.

4. In multiport gateways, reusing a single TCP connection for multiple simultaneous sessions has several problems: - TCP requires sequential delivery: if a segment with signaling in it for one session needs to be retransmitted, segments behind it, with signaling for other sessions, are delayed; hence, many sessions can be delayed because of a retransmission in another session's signaling; - TCP rate control is not appropriate for connections that carry signaling for multiple simultaneous sessions and can lead to severe performance problems. SCTP was developed in response to these problems, but is not yet widely supported and deployed. Again, IMHO, UDP is the best solution.

I will agree that text in general, SDP in particular, is very compressible and that SIP has good support for message compression. But again, this is an optional capability. If every endpoint and proxy supported it I wouldn't have a problem with relying on it. And while, unlike the use of TCP and SCTP, I strongly support and encourage the use of SIP message compression, I don't think we should be relying on it (Until it's support is mandatory, which I also strongly support and encourage, and is widely deployed! :-) )

...

The SDP isn't so much a problem as the SIP:

If the problem is not in SDP, then it shouldn't be solved there. As noted above, there are already solutions to the SIP problem.

I didn't say there wasn't *any* problem with the SDP, or that small SDP size could completely solve the problem. But if everybody depends on everybody *else* to solve a shared problem, the problem never gets solved. In fact, the problem may not get solved unless *everybody* *does* contribute to the solution. To the extent that MoIP SDP contributes to the problem, it has to contribute to the solution. As with ecology: think globally, act locally.

As noted above, I disagree that the things you noted above are acceptable solutions, except maybe for SIP message compression.

Finally, going back to the top of your message:

Given the cons of this scheme, there would have to be an exceptionally strong motivation for

doing it

(which I haven't seen).

To my mind, the issues that I've stated above provide more than enough motivation for us to do everything we reasonably can to keep the MoIP SDP size as small as possible.

Comments expected and welcome.

Jim