[Asterisk-Users] SIP config documentation

[Fran Boon]

On Sat, 2004-02-21 at 11:48, Olle E. Johansson wrote:
> canreinvite has yes|no|update as keywords.
> with UPDATE a SIP method UPDATE is initiated to change the media path.
> with YES, a new INVITE is issued within the current call. (a "re-invite")
> with NO, the call stays within asterisk.

Any ideas on when UPDATE would be better than the standard re-invite?

> >>>callerid= ; U- caller id of the user: "Name <number>".
> >>Have to check this one. Been working a bit on this problem in the
> >>chan_sip2 channel.
> > I have submitted two bug reports. One includes a patch to chan_sip.c that
> > fixes the problem. See:
> > http://bugs.digium.com/bug_view_page.php?bug_id=0001074
> > Another is about CALLERIDNUM. This variable seems to strip the dots from
> > the domain without practical reason (also SetCIDNum and the like do this).
> > See:
> > http://bugs.digium.com/bug_view_page.php?bug_id=0001075
> I'll add comments to the bug reports. We really need to think about how
> we steer the SIP channel forward. Asterisk is a multi-protocol PBX, so
> there's no sense in making the SIP channel a stand-alone SIP proxy that
> doesn't work with the rest of the PBX. If you don't want a PBX in the core
> of your SIP network, use a SIP proxy there and use Asterisk where it fits
> in. This way of reasoning means there are things that will never happen in
> the Asterisk SIP channel because of the multi-protocol architecture. We need
> to be clear on that while moving the channel forward.

Could different options be used in different channels?
i.e. if the SIP user is calling a Zap channel, then you'd use only
standard numerical CallerIDs.
However, if the SIP user is calling another SIP user, then these new
patches would kick in & you'd be able to have full SIP URLs viewable :)

> Having said that,
> there's a lot of things to do to make the SIP client and server within
> Asterisk more compliant and functional with the rest of the SIP world.

Yes, please :)

> I do want Asterisk to be in the forefront in preventing
> use of Asterisk as a open SIP spam relay to use mail terms. Mail servers are
> picky of which domains they server for inbound and outbound messages, in some
> cases also on what domain is used for outbound messages. We need to have
> configuration that follows this line of thinking for SIP. If someone is using
> our domain for outbound calls - authenticate. If someone is randomly placing
> calls to extensions in any domain they invent *into* our PBX, don't answer.

This is good thinking - the idea of VoIP spam fills one with horror!

> >>As I stated earlier, I'm highly suspicious to the "in order of
> >>preference"
> >>part. Since I got no comments or replies on that mail, I suspect I'm
> >>right
> >>:-) 
> > What do you mean? Is the order of preference not working?
> I've checked into this since no one else bothered... :-)
> Allow/deny codecs in the [general] section have an order of preference, it is
> correct. Allow/deny codecs for peers/users have no order of preference, it's
> just a matrix of codecs we can use for calling them.

This looks like a BUG to me!
Is it only evident in the SIP channel, or in others (such as IAX) as
well?
I can't find it in the BugTracker - is it there?
Sounds easy to fix, but that's easy for me to say, since I'm not a coder
;)

> > A new question:
> > Is chan_sip2 ready for production?
> I'm using it in my production servers, but I wouldn't recommend it to anyone else
> for more than testing at this time.
> It's beta and I'm adding new stuff constantly, propably new bugs as well.
> Have got some very useful feedback (thank you, Fran!) but need much more from
> testers.
> It adds a lot of features, like templates and MYSQL authentication. Adding features
> is dangerous without testing, so please help me test this little creature.

I'm testing Asterisk in a SIP-only environment using this version of the
channel. I don't yet run a full Production system, but test this with
X-Lite, ATAs & 7960s....works great so far :)

F