[VOIPSEC] 4G Issue Map: signaling complexity

Sat Aug 26 00:09:01 BST 2006

At 03:55 AM 26/08/2006, you wrote:
>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.

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#Remote_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...?

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_Paper.pdf

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