[Asterisk-Users] SIP config documentation

[Olle E. Johansson]

Costa Tsaousis wrote:

>>>context= ; UP, the context name for placing calls
>>>
>>>Q1: Why is there a context for peers?
>>
>>We use peers in some other situations as well.  This is strange and
>>rather undocumented, but an incoming call is first matched by
>>username with the defined users (including 'friends'). After that,
>>we match on IP address with the peer table. Hopefully those
>>peers have authentication (a secret), so we authenticate and accept
>>the call based on IP. This is used when connecting Asterisk as
>>a PSTN-gateway to other SIP proxys. Incoming calls are placed
>>in the peer context.
> Does this mean that if I have SER for example as the primary proxy for a
> domain and I want to use asterisk as a media gateway, I can have SER
> redirect my user agents to asterisk, which will be authenticated as nomral
> by asterisk (sip.conf entries for each agent), without using
> autocreatepeers=yes?
Yes, if you're in the same realm and using the same user definintions,
you can do it without autocreatepeer. But that means you're not using
the above functionality. If you're using the above functionality, matching
peer by IP, there's only ONE peer and if you're using that with auth,
all clients get the same auth.

Feel we need to document various solutions here.
>>>canreinvite= ; UP yes, no or update.
>>>
>>>Q2: What the "update" option does?
>>
>>I think the update is not a keyword, but a value.
> Yes, my fault.
Sorry, I was on the wrong topic, canreinvite has
yes|no|update as keywords.
with UPDATE a SIP method UPDATE is initiatied 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.

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

>>>fromdomain= ; -P Domain to show in the domain field of the outgoing
>>>call TO the peer.
>>
>>I think this is mainly used when we REGISTER with an outbound proxy,
>>like FWD.
>>
>>>fromuser= ; -P User to show in the user field of the outgoing call TO
>>>the peer.
>>
>>Same here.
> 
> fromdomain and fromuser overwrite the callerid sent TO the peer. The
> [general] section fromdomain and callerid are the same respectivelly
> (callerid in [general] is fromuser actually) for destinations not defined
> as peers in sip.conf (i.e. DNS SRV based lookups). The patch I have
> sumbitted above allows the type=user entities to have a
> fromdomain/fromuser given in their callerid:

I need to investigate a bit more here.

> 
> This allows asterisk serve multiple SIP domains concurrently (I am working
> on this for some time - I have build a configurator that automatically
> creates multi-domain configurations for using * for SIP virtual PBX
> services - If you are interested for this builder, just send me a note to
> send it to you - it is alpha currently).
We need to work together to handle the multi-domain scenario. Please
send me whatever you have and let's continue discussing this so we get
a solid architecture. 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.

>>>username= ; -P username to send to the peer when calling the peer
>>>
>>>Q7: Since this is a peer option, it is really very badly documented in
>>>the various documents. All these documents state that this is used
>>>when
>>>the phone's login name is different from the default. But then, since
>>>this is a peer option it is ignored for type=user agents and is used
>>>only when asterisk is calling the phone.
>>
>>Agree, this is fuzzy. Have you noticed that it changes to peer name
>>after a while? Do 'sip show peers' at the CLI, and you'll notice.
>>
>>The chan_sip2 channel uses the Contact: at registration when we
>>send subsequent messages, like INVITE.
> 
> 
> As I see in chan_sip.c/initreqprep() username= is also used in INVITE for
> peers too.
I need to investigate this further.


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

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

For those of you that wants to do anything in the SIP channel, the standard one or
the chan_sip2, the code includes many, many, comments that explains what various
functions do and what various variables are used for.  Again, sometimes it's my
own qualified guesswork, so please help me clarify things there as well if I'm
wrong.

Regards,
/Olle