[Asterisk-Dev] RFC: simplifying sip configuration sections

[Luigi Rizzo]

sip sections are now very long. For the typical provider you
need a number of parameters e.g.

	[provider18]
	type=peer
	secret=mysecretkey
	username=1234567
	regexten=8901234     ; contact, really...
	insecure=very   ; used to prevent auth for incoming calls.
	host=asterisk.myprovider.org
	context=from-provider18
	register=true

and for the typical user phone:

	[7123]    ; ast phone
	host=dynamic
	type=friend
	secret=anothersecretkey
	username=7123
	nat=yes
	canreinvite=no  
	context=localphone

I would propose shortening them in a way similar to the one used
for 'register= ...' i.e. put in a single line most of the info, and
use sensible defaults. With my proposal the above would become

    [provider18]
    peer= 1234567:mysecretkey at asterisk.myprovider.org/8901234 at from-provider18

    [7123]    ; ast phone
    friend= :anothersecretkey at dynamic/@localphone
    nat=yes
    canreinvite=no ; maybe default when nat=yes

In practical terms, the main entry would be of the form

    T= username[{:secret|#md5secret}[:fromuser]]@host[/regexten at context]

where the arguments on the right hand side supply the values for the
corresponding long-form variables, and T is either peer, user or friend
to represent 'type=peer|user|friend' in the long form, respectively.

Defaults, special values and side effects are as follows:
    username	an empty username is replaced by the section's name
		(typical for phones maybe)
    host	the special value 'dynamic' means host=dynamic
    regexten	if empty, it is taken from 'username'. regexten is
		really the 'contact' in the register= line, but since
		the two should normally match i don't think there is
		much of a problem.
    secret	if supplied and T=peer, then implies register=true

Also, we could introduce a side effect on 'nat=yes' to imply
'canreinvite=no' (typical source of trouble with nat's ?)

Also, partly related:
I have an issue with "insecure" : basically in my limited
world, when i connect to external providers, i always need to
use "insecure=very" to let incoming calls be accepted without
asking for credentials. Could someone explain when different
default settings of "insecure" are desirable ?

As a consequence, i would be inclined to make "insecure=very"
the default when dealing with a "peer" entry.

Of course the old-style commands remain available and can be used to 
override unwanted defaults.

	comments ?

	cheers
	luigi