[VOIPSEC] 4G Issue Map: signaling complexity

Sun Aug 27 02:38:51 CDT 2006

Simon,

> I can certainly understand how you provide NAT support for calling
from
> behind a far end NAT but what about calling to it?
> I was reading this
> http://sipx-
>
wiki.calivia.com/index.php/HowTo_configure_SIParator_to_work_with_sipX#R
em
> ote_NAT_Traversal
> Is it true you have to manually set the external IP address of the
NATed
> sip client and have it re-register every 20 sec...?

No, you do not need to set any external IP address manually this may be
something special for sipX, I don't know. And you do not need the set a
re-registration timer on the client this is done on the Ingate only and
there are two ways to keep the signalling path through the NAT open;
using short re-registration intervals or sending OPTION packet with
short intervals. If you use OPTION or re-registration to keep the
signalling path open is up to the Ingate administrator and depends on
the clients used. And the user does not need to do any special settings
on the client and can move between the office and remote sites as they
want, it is a key feature to make it transparent for the user.

By keeping the signalling path open as described above requests will
reach the NATed client and media works as long as symmetric RTP is used.

> BTW: Here is a good overview of how the ITU have approached
NAT/Firewall
> traversal and the applicable standards H.460.17/18/19.
>
http://www.h323forum.org/papers/301005_Firewall_NAT_Traversal_White_Pape
r.
> pdf

Thanks.

/Janne

> 
> 
> Simon
> 
> 
> >/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
> > >
> 