Subject: Re: [SIP] a tiny binary sip proxy protocol

From: Kim Liu <[email-masked]>
Date: Tue, 02 Jan 2001 10:12:55 -0500

Ashhar Farhan wrote:

> i am proposing a very easily implemented, binary level protocol that can easily translate to and from sip
> signalling. the protocol is right now called STP (Sip's Tiny Proxy).

Interesting.  I have been wondering if someone would work out something more efficient for machine-to-machine signalling.

There's some potential there, but it needs to be fleshed out more.

Kim Liu
Senior Software Engineer
[email-masked]

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

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 2 Jan 2001 14:31:44 -0500

The idea of a "SIP Lite" sounds interesting.  However, what benefit do you
see by having the protocol binary?  With shorts and ints, you run into
network byte-order problems.

What precisely does the proposal try to fix?  Items 3 and 4 could be useful;
does anyone else on the list have an opinion

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ashhar Farhan
> Sent: Saturday, December 30, 2000 3:13 AM
> To: [email-masked].
> Subject: [SIP] a tiny binary sip proxy protocol
>
>
> i am proposing a very easily implemented, binary level protocol
> that can easily translate to and from sip
> the protocol has the following features:
>
> 1. it can painlessly traverse SOCKS 5 proxies, NAT and other
> forms of proxy like WinSock. It uses in-band signalling so that a
> single port on proxies and firewalls is used for both streaming
> as well as signalling. This is an issue of immense importance
> currently. Most of the people who have an always on presence on
> the Net are usually behind a proxy of some sort.
>
> 2. the signalling uses binary structures that can be directly
> read into C structures eliminating the need of costly parsers.
> This leads to a loss of many facilities inherent in SIP. This is
> by design. It is a cut down protocol that can easily translate to
> SIP through a gateway.
>
> 3. All the signalling messages are handled uniformly (retransmit
> until response or time-out). forking is not allowed. INVITE and
> ACK are replaced with RING and ANSWER (as two separate messages).
>
> 4. No call parameter renegotiation is allowed.