Hello!
I have installed Asterisk 1.6.2.9-2 on Debian Linux. Configured it( as I suppose correct). But Asterisk ignore context.
ie. I have following sip.conf
If in sip.conf default context nope then calls from CUCM are not accepted, message is not found. In SIP peer details(sip show peer CUCM) context is correct (provOUT). The same problem with phL1 and phL2. phL1 do “not see” context, when phL2 work correct. I know that now little mistake with phL1, but there is problem too.
If I am changing register => 1262454204:password1@sip.prov.kz to register => 1262454204:password1@sip.prov.kz/phL1 then incoming extensions are not found. But if register => 1262454204:password1@sip.prov.kz, then calls are accepted through 2nd line. Any Ideas ?
The most likely reason for this sort of problem is that the incoming call is not being matched against the CUCM entry. To confirm this, you would need at least verbose console log output. Potentially you may need sip set debug output.
== Using SIP RTP CoS mark 5
== Using UDPTL CoS mark 5
Sending to 192.168.168.96 : 5060 (no NAT)
Found RTP audio format 18
Found RTP audio format 8
Found RTP audio format 101
Found audio description format G729 for ID 18
Found audio description format PCMA for ID 8
Found audio description format telephone-event for ID 101
Capabilities: us - 0x40c (ulaw|alaw|ilbc), peer - audio=0x108 (alaw|g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 192.168.168.96:17162
Looking for 987272222222 in default (domain 172.16.17.148)
<--- Reliably Transmitting (no NAT) to 192.168.168.96:5060 --->
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 192.168.168.96:5060;branch=z9hG4bK29A1A9D;received=192.168.168.96
From: "Alexandr " <sip:113@192.168.168.96>;tag=61FBA98-11DF
To: <sip:987172222222@172.16.17.148>;tag=as09632286
Call-ID: BE4AFC90-D13911DF-8F009257-79A3AE2A@192.168.168.96
CSeq: 101 INVITE
Server: SipperLite
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog 'BE4AFC90-D13911DF-8F009257-79A3AE2A@192.168.168.96' in 32000 ms (Method: INVITE)
Really destroying SIP dialog 'BE4AFC90-D13911DF-8F009257-79A3AE2A@192.168.168.96' Method: ACK
same thing with phL1, how it could be?
how debug peer searching ?
I always get confused by the exact rules, when there are possibilities of both name and address matches, so I don’t think I can give a quick, reliable, answer.
However, you may want to set allowguest to no, to improve the system security.
That’s what I would have expected. The suggestion was made to ensure that intruders were blocked as early as possible, rather than to ensure you matched the correct entry.
Ian: he’s already accepted that it is matching the default context. What he is after now is why it isn’t matching the CUCM entry in sip.conf. I don’t do this often enough to remember all the subtlteties.
Ian, I do not understand you. Call coming from host 192.168.168.96 , To: sip:987172222222@172.16.17.148 where 172.16.17.148 - asterisk ip, 987172222222 - called number which represented in provOUT context. It should be matched because in sip.conf friend called CUCM has host=192.168.168.96.
Found : If in peer CUCM set insecure=port,invite, then Asterisk start find in correct context. Is it correct behavior?
ie. I came to next, I should identify peer by it IP address.
