Коллеги!
Помогите советом.
Ситуация такова: есть UBUNTU desktop, на нём Asterisk только, что установленный. Есть такой же рабочий сервер Asterisk c рабочими sip.conf и extensions.conf. Пробовал писать sip.conf и extensions.conf, в конце концов взял с рабочего сервака и перенес на новый. Результат один - клиенты не регистрируются (как аппараты Linksys spa 942 так и Xlite). Откуда начать копать?

ммм. если это сообщение значит "рабочий сервер отливал другой человек, я сам Астариск первый раз в жизни вижу" то начинать с чтения. Что нибудь отсюда http://asterisk.ru/knowledgebase/books и http://asterisk.ru/knowledgebase

1. extensions.conf к _регистрации_ клиентов отношения не имеет, можно пока отложить.
2. пользователи могут быть прописаны в users.conf - его тоже стоило скопировать
3. пользователи вообще могут быть в базе. (это таки на случай если таки не вы рабочий ставили и не знаете что там и как)
4. в sip.conf могут быть IP адреса машины (bindaddr) надо не забыть поправить
5. ну и в iptables не забыть разрешить SIP

Если все это проверено - то лог консоли и sip debug.

Ну скажу так:
1) Я конечно не супер спец, скажем даже так, что новичое, но север рабочий поднимал я сам впервые и он до сих пор работает.
2) Users.conf на рабочем сервере вообще не трогал.
3) в bindaddr указан IP той машины, которую настраиваю.
4) что-то разве специально надо разрешать iptables? на прошлом серваке специально ничего не прописывал

Вот нарыл в логах: [Apr 15 01:39:00] WARNING[5141] chan_sip.c: Failed to bind to 192.168.1.83:5060: Cannot assign requested address
Это как так он не может себе адрес назначить?

Покажите вывод команды:

CLI> sip show peers

ну и sip.conf ...

Сейчас пробуют регистрироваться 100 и 101
AIRPBX*CLI> sip show peers
Name/username Host Dyn Nat ACL Port Status
1111/1111 (Unspecified) D 0 Unmonitored
1003/1003 (Unspecified) D 0 Unmonitored
102/102 (Unspecified) D N 0 Unmonitored
101/101 (Unspecified) D N 0 Unmonitored
100/100 (Unspecified) D N 0 Unmonitored
5 sip peers [Monitored: 0 online, 0 offline Unmonitored: 0 online, 5 offline]

sip.conf
[general]
context=default
allowoverlap=no
bindport=5060
bindaddr=192.168.1.83
srvlookup=yes
videosupport=yes
useragent=AIR-ASTERISK
;register => *****:*******@sipnet.ru/********

[100]
type=friend
context=phones
host=dynamic
nat=yes
language=ru
secret=100100
username=100
callerid=100 <100>

[101]
type=friend
context=phones
host=dynamic
secret=101101
username=101
nat=yes
language=ru
callerid=101 <101>

[102]
type=friend
context=phones
host=dynamic
secret=102102
username=102
nat=yes
language=ru
callerid=102 <102>

[1003]
type=friend
context=phones
host=dynamic
secret=123456
username=1003
nat=no
language=ru

[1111]
type=friend
context=phones
host=dynamic
secret=123456
username=1111
nat=no
language=ru
callerid=1111 <1111>

[sipnet]
type=friend
username=*****
secret******
callerid=*******
host=sipnet.ru
nat=yes
fromuser=*****
fromdomain=sipnet.ru
dtfmode=rfc2833
insecure=very
context=SipNet
disallow=all
allow=alaw

Ну это значит что не может астеериск слушать порт 5060 на IP адресе 192.168.1.83. Собственно вероятные причины:
1. это НЕ IP адрес этой машины - проверьте ifconfig
2. порт 5060 уже кто-то слушает - другая ккопия астериска или кто-то еще.

netstat -pna | grep 5060

4) что-то разве специально надо разрешать iptables? на прошлом серваке специально ничего не прописывал

я не знаю стартует ли в убунту по умолчанию iptables и какой у него дефолтный конфиг. Но если стартует и конфиг запретительный - то да, надо прописывать.

В Ubuntu, все дефолтные чэйны в iptables в ACCEPT'e. Так что это точно не сетевой фильтр мешает, если вы его сами руками не трогали, ес-но

$ sudo iptables -L

P.S. Судя по тому что Ubuntu desktop, на той же машине установлен софтфон, который занял UDP 5060. Если так, меняйте в софтфоне порт, например на 5061

root@AIRPBX:/home/air# netstat -pna | grep 5060
udp 0 0 192.168.1.83:5060 0.0.0.0:* 6357/asterisk

pid 6357 - именно от моего астериска!

Софтфон на другой машине.

sip set debug:
<--- SIP read from 192.168.1.131:5060 --->
REGISTER sip:192.168.1.83 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.131:5060;branch=z9hG4bK-eed7e38a
From: "100" <sip:100@192.168.1.83>;tag=11a33277aeaf4e64o3
To: "100" <sip:100@192.168.1.83>
Call-ID: aae447b-b07dc205@192.168.1.131
CSeq: 24007 REGISTER
Max-Forwards: 70
Contact: "100" <sip:100@192.168.1.131:5060>;expires=3600
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces


<------------->
--- (12 headers 0 lines) ---
Using latest REGISTER request as basis request
Sending to 192.168.1.131 : 5060 (no NAT)
AIRPBX*CLI>
<--- Transmitting (NAT) to 192.168.1.131:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.131:5060;branch=z9hG4bK-eed7e38a;received=192.168.1.131
From: "100" <sip:100@192.168.1.83>;tag=11a33277aeaf4e64o3
To: "100" <sip:100@192.168.1.83>
Call-ID: aae447b-b07dc205@192.168.1.131
CSeq: 24007 REGISTER
User-Agent: AIR-ASTERISK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0


<------------>
AIRPBX*CLI>
<--- Transmitting (NAT) to 192.168.1.131:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.131:5060;branch=z9hG4bK-eed7e38a;received=192.168.1.131
From: "100" <sip:100@192.168.1.83>;tag=11a33277aeaf4e64o3
To: "100" <sip:100@192.168.1.83>;tag=as5b3a0216
Call-ID: aae447b-b07dc205@192.168.1.131
CSeq: 24007 REGISTER
User-Agent: AIR-ASTERISK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="5b29a412"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'aae447b-b07dc205@192.168.1.131' in 32000 ms (Method: REGISTER)
[Apr 15 11:19:04] WARNING[6795]: chan_skinny.c:4502 get_input: Skinny Client sent less data than expected.
[Apr 15 11:19:04] NOTICE[6795]: chan_skinny.c:4561 skinny_session: Skinny Session returned: Success
[Apr 15 11:19:04] WARNING[6796]: chan_skinny.c:4502 get_input: Skinny Client sent less data than expected.
[Apr 15 11:19:04] NOTICE[6796]: chan_skinny.c:4561 skinny_session: Skinny Session returned: Success

Включите на клиенте авторизацию - он даже не пытается выслать повторный invite в ответ на требование WWW-Authenticate :)