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

From: "Ashhar Farhan" <[email-masked]>
Date: 3 Jan 2001 05:39:58 -0000

eric wrote -
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.

keeping the protocol binary eliminates the need for a parser completely. you can directly copy the incoming udp packet into a sip lite structure and that is it. this is exceedingly important for making sip lite easy to understand.

the network byte-order will only be a problem for the command and the version fields. the ip addresses, ports and session ids dont need to arithematically manipulate their bits, so the network byte ordering is not a problem.

- [email-masked]

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com

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

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Jan 2001 14:35:06 -0600

True. It's amazing how much hton, ntoh, and the MS MFC classes do for you
when you really look at what's going on.

Brian

-----Original Message-----
From: David Frascone [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 3:13 PM
To: [email-masked]
Subject: Re: [SIP] a tiny binary sip proxy protocol

And, don't forget about byte alignment across architectures.  Try to view a
short on a 16 byte boundry on a 64 bit processor that wasn't made by INTEL.

On Wed, Jan 03, 2001 at 02:26:35PM -0600, Brian Stucker wrote:
> Hmm... Some machines use big-endian formats for their bytes, and others
> little-endian. So you still have the problem of which bit of a byte is
> considered most significant.
> 
> Intel uses little-endian, in which the leftmost bit is the least
> significant. Other manufacturers use big-endian in which the rightmost bit
> is the least significant.
> 
> So just copying bits off of a NIC into a struct of some sort, without
regard
> to the formatting of those bits, even within a single byte, can be
> problematic.
> 
> Brian
> 
> 
> 
> -----Original Message-----
> From: Ashhar Farhan [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2001 11:40 PM
> Subject: RE: [SIP] a tiny binary sip proxy protocol
> 
> 
> eric wrote -
> 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.
> 
> keeping the protocol binary eliminates the need for a parser completely.
you
> can directly copy the incoming udp packet into a sip lite structure and
that
> is it. this is exceedingly important for making sip lite easy to
understand.
> 
> the network byte-order will only be a problem for the command and the
> version fields. the ip addresses, ports and session ids dont need to
> arithematically manipulate their bits, so the network byte ordering is not
a
> problem.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 4 Jan 2001 01:31:39 -0500

And more importantly, this is nothing more than yet another signaling
protocol for VoIP. If you wish to propose a new working group in IETF to
standardize such a thing, you are welcome to try. However, it is not SIP and
discussion of this new protocol does not belong on this list.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 4:07 PM
> To: Brian Stucker
> Cc: Ashhar Farhan; [email-masked]
> Thanks for solving a non-problem (parsing expense). Can we move on to
> other, more pressing concerns?
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>