Subject: Re: [SIP] Transports again

From: [email-masked]
Date: Tue, 13 Jun 2000 09:42:49 +0530

Hi, thought Id put in my 2c worth:
(responses preceded by ARC> )

>
> Hmm... embedded systems may well have as hard a time supporting the
> retransmit-logic and storage implied by SIP-over-UDP - That software
> is not *yet* available completely off the shelf, whilst TCP stacks are.
> It's not the development time that's a problem here - it's the size and
> application processing requirements of the eventual product.

Speaking from personal experience, with a lab that has developed a stack
for both networking and SIP: TCP would have been far more complex than
the trivial retransmit timer in SIP. For us, that's as much a code space
problem as a development time problem.

ARC> We have done a lot of porting of the SIP Stack on various embedded
systems
ARC> and the retransmission logic/ availability of a UDP stack was of no
concern
ARC> at all. As far as the retrans logic was concerned, it did not affect
performance
ARC> or run time overhead enough for us to look back at it.
ARC> However,  I would like to know of common RTOSes which dont have UDP
ARC> support (so I can be prepared when we attack that RTOS next ;-)

> device, then I would expect it to talk over UDP, unless it states that
> it only talks over TCP. I just believe that a TCP-only device should be
> a valid sub-set - but any such product had better state that it supports
> only this sub-set. Isn't that the sense of SHOULD?

My perception is that items crucial for basic interoperability are
labeled MUST, while those more on the margins can be SHOULD.

ARC> Couldnt agree more. Its great to know that we have atleast one
protocol
ARC> which we know will be supported by others. If both are made SHOULD, im
pretty
ARC> sure in the next bakeoff we will have a lot of new ones. half
supporting only TCP
ARC> and the other only UDP who wont be able to talk to each other. I do
understand
ARC> your point that why use UDP if my network doesnt need it ? Its a
tussle b/w
ARC> your needs and making a minimal set of SIP fixed so that in broader
interworking
ARC> scenarios, there is lesser of ambiguity. If you say your n/w doesnt
need UDP
ARC> how about doing only TCP, and returning a final response Error of
something
ARC> like 300 (Protocol not allowed) (actually that was for SDP - sometinng
similar ?)
ARC> so that the sending terminal at least knows you are up and dont accept
UDP without
ARC> him trying to figure out if you are really up, or putting in extra
logic at the
ARC> sender to try TCP next... Not sure if this would be of any help though
(?)
ARC> However, im against suggesting this behaviour in the base spec for
reasons I mentioned
ARC> previously.

Regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip