Subject: Re: Buddy Lists and UDP max MTU size

From: [email-masked]
Date: Wed, 30 Jun 1999 12:42:36 +0530

jdr> If the packets are really big, use TCP. If the registrar has a list of
jdr> contact addresses which is too long, it should redirect the calling
jdr> party to try TCP:
jdr> 300 Too Big
jdr> Contact: sip:registrar.com;transport=tcp

Well I dont feel that just to get data >1 UDP size, I need to change the
complete protocol. I would surely not like to use TCP as it increased
management load on my server side maintaining one socket connection each
for new clients.
A user list is something which Iexpect my clients to execute probably once
before he wants to see people he can talk so -- so the occurence is not
real time - just for a buddy list, I dont want him to change to TCP (which
again means that for big buddy list (not so big that UDP is inapproriate)
the Clent server have to implement the TCP support too). Although the buddy
list is only one instance, I feel its a veryt important one -- everyone
wants to know who is currently logged in, otherwise they dont know who to
call !

jdr> 1. a registrar cuts off the list of Contact addresses in the 200 OK if
jdr> it becomes too big, rather than redirecting to TCP

This,I think is best avoided. The users will get an incomplete list and
would never know an 'unlisted' person is logged in.

I understand your point that currenlty in normal sip operation, this is
unlikely. However, I dont think its a bad idea to add a 'More-Fragments'
Boolean field at the SIP layer which is optional and will specify that the
message is continued in succeeding datagrams. I feel this is a more elegant
solution than going the TCP way.
Again, currently this might be applicable to a narrow domain, but I think
an extra optional field as above will only add to SIP handling scenarios
(if they occur in future) for multiple application layer fragments.

Regds
Arjun

---

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 30 Jun 1999 04:15:29 -0500 (CDT)

>(if they occur in future) for multiple application layer fragments.

What you propose -- fragmenting UDP within the SIP framework --
would require a substantially larger investment than you suggest.
The major issue you are failing to consider is implementation of
reliability. Would we ACK the first packet *and* each subsequent
"linked" packet? If so, you'll need to add semantics for timing
between packet segements.  If not, what if the first packet is 
dropped and all we get is a "continued" packet? The major
problem is that it introduces significant signalling differences
between SIP for UDP and SIP for TCP.

I'm not saying that  your concerns are unjustified; merely
that they don't fit well into the current SIP protocol without
a significant change in the specification *and* existing
implementations.

Finally, it seems a bit odd that you're implementing some obviously
proprietary semantics for the REGISTER method, yet seeking to
solve a problem it creates with a modification to the standard.

You may want to examine the SIP for presence and SAP drafts
before you continue down a road that will not interoperate
with other implementations. At the very least, consider using
standard message semantics, such as sending your buddy list
back to the client in a series of REGISTER messages instead of
in a REGISTER response.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA