[Asterisk-Users] SIP config documentation

[Olle E. Johansson]

Costa Tsaousis wrote:
> 
> I was trying to figure out all the valid options for a sip.conf and I
> believe I found a few weird things (or just a few things that are weird
> to me :) Anyway, I decided to post this here together with my questions
> and notes in case other people need this info too or have similar
> questions.
Costa,
Thank you for an excellent document. I'll try to merge this into the
wiki docs. I just recently checked what's valid for users and peers
for the chan_sip2 code. You'll see my table in there. Also, in that
beta version of the SIP channel, you'll find some more documentation
and some minor fixes.

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

> canreinvite=	; UP yes, no or update.
> 
> Q2: What the "update" option does?

I think the update is not a keyword, but a value.
See here
http://www.voip-info.org/wiki-Asterisk%20sip%20qualify

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


> 
> callgroup=	; UP
> pckupgroup=	; UP
> 
> Q4: Since a user cannot accept calls, why to setup call pickup for
> him/her?
Sorry, haven't used or checked call groups. Anyone else?


> 
> language=	; U- language for voice messages and indications
> 
> Q5: Why a peer does not have a language? What if we want to call someone
> with an IVR menu (via a .call file)? How we can choose the language for
> him/her? (yes, I know this can be set in the context the call will
> enter, but I think the elegant solution is to have this information
> here).

This is a bug fixed in the chan_sip2 channel.


> accountcode=	; U- CDR's account code
> incominglimit=	; U- concurrent call limitations ( >= 0 )
> outgoinglimit=	; U- concurrent call limitations ( >= 0 )
> 
> Q6: How is it possible for a type=user phone to have BOTH incoming and
> outgoing limits?
Interesting question. Anyone else?


> nat=		; -P yes, no : Support NAT. (breaks RFC)
Well, yes, it breaks the RFC, but makes SIP work. What nat=yes really does
is that it ignores the IP data within the registration or invite and use
the IP address Asterisk received the packet from. This works if the
client is contacting us directly, with no outbound proxy in between.
This is rather common in SIP proxy implementations right now. When STUN
and UPNP and other NAT/VoIP solutions are more frequently implemented,
the data sent to thte SIP server will not include any private NAT networks
any more, but that will not happen overnight.

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

> mask=		; -P netmask for host= parameter.
This has to be defined *before* thet host= parameter.
What it does? Don't know. Anyone else? Why do Asterisk apply a host mask to
an IP address for a host?
> port=		; -P port for host= parameter.
If host=dynamic this applies to defaultip.
> defaultip=	; -P if the peer does not register with us, where we should
> try to find it by default.
Useful if you restart Asterisk. The SIP device think it's registred for a
while longer, but Asterisk lost contact with them.

> Q7: I am really lost with these. I understand defaultip pretty well, but
> then, what is exactly the use of host, port and mask, for peers? Does
> this have to do something with nat=yes in order to set our asterisk
> "public view", or what?
host=<ip address>
port=<port no>
means you don't use SIP REGISTER, the SIP ua is always at the same address.
Again, mask - I don't really know.

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

> context=	; Default context for incoming SIP calls
not coming from users or peers (by IP address)

> language=	; voice messages language
Not only voice messages, also sets indications.

> callerid=	; Default caller id (name only & becomes fromuser too)
> 
> The effects of the callerid option are very funny. The only thing that
> produces valid SIP headers is just a word. The default is: asterisk
Have you noticed that the realm in authentication is always "asterisk".
In chan_sip2, you can configure this to your domain (also according to
the RFC).

> autocreatepeer=	; Automatically create peers from incoming calls?
The peer is created by incoming registrations.

> localnet=	; ???
> localmask=	; ???
> externip=	; Address that we're going to put in SIP messages if we're
> behind a NAT
These three options are involved in NAT handling for outbound calls to SIP
proxies we register with. Localnet/localmask is used to determine wheter to
use the externIP or not.

> disallow=	; Disallow codecs
> allow=		; Allow codecs in order of preference
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 :-)

As you've noted, there are things to fix in the SIP channel.

/Olle