[VOIPSEC] 4G Issue Map: signaling complexity

Fri Aug 25 14:55:24 CDT 2006

Hi Simon,

> >I've been using SIP phones for more than two years now and it works
just
> >fine without any STUN/ICE (just an Ingate SIParator in our office)
from
> >home, hotels around the world, trains and airplanes etc. (It is
pretty
> >cool to sit in an airplane and answer your office phone :)
> 
> That is going to be a bit tough to do now because Boeing have just
pulled
> their in-flight Internet. :)
> http://www.msnbc.msn.com/id/14393300

Too bad, it was a really nice thing.

> Besides what is the NAT traversal RFC you are using?
> Working outside the IETF is one of the key points of the article I
posted
> earlier about the future of SIP.
> http://www.dailypayload.com/cgi-bin/news?n=2304

The NAT traversal technique we use is not specifically defined by any
RFC but the important thing is that we don't violate any RFC and it
works well with any SIP client without any kind of special setting. 

/Janne

> 
> 
> >I share your experience. My biggest problem is that too many of those
I
> >want to call lack a SIP address so I have to use the PSTN gateway.
> 
> The real problem is security (SPIT basically). Without any form of
> unregistered caller admission or caller authentication in SIP,
allowing
> unregistered callers to call it the network is thwart with huge
danger,
> the
> bigger the network the larger the target you become. Recently
companies
> like sipgate www.sipgate.com (european provider) have completely
closed
> off
> unregistered caller access (SIP URI) to their network for security
> reasons.
> Without any security framework it is going to be difficult to get
anyone
> to
> open their SIP networks. It's looking more and more likely the SIP
VoIP
> islands are going to persist into the forseeable future.
> 
> Simon
> 
> 
> >/Janne
> >
> > > I think Skype has taught me a lot.  I don't think many people on
this
> >list
> > > get it:
> > >
> > > You can have complete signaling security, every time.
> > >
> > > You can have excellent quality audio, except when you go to the
PSTN,
> >and
> > > even then, the average Skype out call sounds much better than the
> >average
> > > PSTN caller.  VoIP without wideband should never have existed.
> > >
> > > You don't need many features, and some of the ones you need don't
> >exist in
> > > the PSTN (like portable phonebooks and chat).
> > >
> > > Telephone numbers are starting to be less important
> > >
> > > We still don't know what a sustainable revenue model is, but it's
> >highly
> > > unlikely to look like the current one.
> > >
> > > What have you learned?
> > >
> > > > -----Original Message-----
> > > > From: Simon Horne [mailto:s.horne at packetizer.com]
> > > > Sent: Thursday, August 24, 2006 7:09 PM
> > > > To: Brian Rosen
> > > > Cc: voipsec at voipsa.org
> > > > Subject: Re: [VOIPSEC] 4G Issue Map: signaling complexity
> > > >
> > > >
> > > > Brian
> > > >
> > > > Customers don't care whether it's text or binary, they just care
> >that it
> > > > works and whether it can it deliver the solution to the customer
> > > > requirements and that today includes PSTN integration, Security
and
> >NAT
> > > > Traversal.  As SKYPE would say, arguing about which or what is
> >better is
> > > > just purely academic. Can you deliver the solution? The truth is
> >after
> > > 10
> > > > years with SIP we're all still scratching our heads.
> > > >
> > > > Simon
> > > >
> > > > At 06:00 AM 25/08/2006, you wrote:
> > > > >Paul
> > > > >
> > > > >Re: Text vs Binary.
> > > > >
> > > > >I was there.  I was the IETF editor for the first Megaco RFC.
The
> > > design
> > > > >was a compromise.  You can say, after the fact we could have
done
> > > better,
> > > > >and no doubt that was true.  However, the text guys will tell
you
> >the
> > > > same
> > > > >thing: if they could have ignored the binary guys, they could
have
> >done
> > > > >better.
> > > > >
> > > > >The only think I have heard that MAY have some validity is that
the
> > > > binary
> > > > >guys should have pushed PER instead of BER.
> > > > >
> > > > >I don't understand the compress SIP issue.   If you have a SIP
> >device
> > > on
> > > > a
> > > > >network with hundreds of kilobits or megabits or gigabits of
> >bandwidth,
> > > > then
> > > > >you can ignore compression; not worth it.  When you are on a
device
> > > that
> > > > has
> > > > >kilobits of signaling channel, then compression is a good idea.
> >SIP
> > > > >compresses well, without significant compute expense.  I don't
> >think
> > > > ASN.1
> > > > >would compress well.  I'm not sure I've actually seen anyone
try,
> >but
> > > > many
> > > > >the normal compression tricks wouldn't work well except on the
> >obvious
> > > > >repeated URI stuff, which is text always.
> > > > >
> > > > >What we have discovered about text encoding is that they are
much
> > > easier
> > > > to
> > > > >get right IN THE BIG PICTURE.  They are much, much easier to
debug.
> > > > >
> > > > >The usual claimed ASN.1 advantage beyond message size is the
> >automatic
> > > > >syntax correctness.  My personal experience with that is that
it's
> >true
> > > > on
> > > > >the wire, but not in the implementation.  It takes more time to
get
> >an
> > > > >interoperable implementation with ASN.1, because it takes more
time
> >to
> > > > get
> > > > >through the edit/compile/test loop, and it takes longer to
> >diagnose.
> > > > Once
> > > > >you have the implementation working (and I mean interoperable)
the
> > > > >correct-by-construction syntax advantage goes away.  The thing
that
> > > > >surprised me the most was watching bakeoffs (sorry Pillsbury).
> >ASN.1
> > > > based
> > > > >bakeoffs are painful, text ones are much, much easier.  Total
time
> > > > clearly
> > > > >favors text in a bakeoff.  Syntax errors are easy to diagnose
and
> >fix.
> > > > >Semantic errors are much harder, and diagnosing them when you
> >fumble
> > > with
> > > > >your decoding tools is hard.
> > > > >
> > > > >Also, of course, we're a whole lot better with our ABNF parser
> >tools
> > > now.
> > > > >
> > > > > > > If we were to start over in the IETF, the golden rule
would
> >be:
> > > This
> > > > > > > protocol is NOT INTENDED to replace the PSTN, and any
> >suggestion
> > > > that a
> > > > > > > feature is needed because the PSTN has it, or does it some
> > > > particular
> > > > > > way,
> > > > > > > is sufficient reason for outright rejection of the feature
or
> > > > method.
> > > > > >
> > > > > > :-)  Yes and no.  When the user attempts to call a remote
party
> >and
> > > a
> > > > > > recording says "the number you've dialed has been
disconnected"
> >is
> > > > played,
> > > > > > that needs to be heard.  It's either that, or devices have
to
> > > process
> > > > a
> > > > > > lot
> > > > > > of different (and equivalent) error codes.
> > > > > >
> > > > > > I was once using a SIP phone that would not properly play
> >in-band
> > > > > > announcements.  It was several days later (when I used my
mobile
> > > > phone)
> > > > > > before I discovered why the phone just kept ringing and
ringing.
> > > > >Thank you.  Couldn't have picked a better example.
> > > > >
> > > > >The bell heads forced sip to implement early media, because
they
> >have a
> > > > very
> > > > >broken billing system, that they insisted had to be copied.
> > > > >
> > > > >Your problem was your phone did not play early media.
> > > > >
> > > > >The sip mechanism is that the end device gives you your error;
> >there
> > > are
> > > > no
> > > > >announcements in audio form played by the far end.  What if you
> >were
> > > > calling
> > > > >someone with a text phone because you are deaf?  Your phone
could
> >text
> > > > you
> > > > >the proper message, the far end can't.
> > > > >
> > > > >If you want media, complete the call.  That's because SIP is a
> >session
> > > > >establishment protocol, and the media is the session.  If you
want
> > > media,
> > > > >create a session.  That, in and of itself, is not the problem.
The
> > > > problem
> > > > >is the BILLING.  They want the session to NOT be established,
and
> >yet
> > > > they
> > > > >want (one way, if you please) media.
> > > > >
> > > > >Early media is a very, very bad idea, and has caused untold
grief
> >and
> > > > >complication in SIP.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >_______________________________________________
> > > > >Voipsec mailing list
> > > > >Voipsec at voipsa.org
> > > > >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > >
> > >
> > >
> > > _______________________________________________
> > > Voipsec mailing list
> > > Voipsec at voipsa.org
> > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 