imam trixbox i asterisk server,ne radi mi od jutros pozivanje u susjednu zemlju prema mobilnim projevima,a pozivi prema fiksnim brojevima idu. Prije je bilo dovoljno povecat neki broj u bilingu pa bi ta opcija proradila,o cemu se sad radi,kako cu provjerit jel taj trunk DDD broj dostupan itd..
pocetnicko pitanje
Zaključano
Zakačeno
Iz asterisk konzole kucaj:
sip show peers
sip show registry
Provjeri dialplan da slucajno nefulas negdje koju cifru i na kraju pokusaj otkaciti trunk pa ga ponovno nakaci!
sip show peers
sip show registry
Provjeri dialplan da slucajno nefulas negdje koju cifru i na kraju pokusaj otkaciti trunk pa ga ponovno nakaci!
Potpis
izmenjeno 1 put, poslednji put dendic 02.04.2015. u 21:52
Izmene poruke
- dendic02.04.2015. u 21:52zapis iz teksta poruke
primjetim svoju ip adresu u peerovima,registry mi ispise vrije po portovima 5060 i 1024.Uglavnom me muci sto mogu pozivat fiksne tel.brojeve a za poziv prema mobitelima javlja unavaible prees # key ??sta dalje imam ovu congestion poruku ..........
CONGESTION "Congestion" is somewhat misleading. Unfortunately at this time (2007-05-17), Dial() returns DIALSTATUS=CONGESTION for pretty much every call setup problem. The reason for this is that Dial() is used for multiple protocols (Zap,SIP,IAX etc.) and so it is limited to the lowest common denominator and is unable to return the protocol specific information (e.g., SIP 404 response) .
There is also currently no way to obtain the SIP response in the dialplan, even though it is reported on the debug console (if debug level >3). Even though one can see every other SIP header with ${SIP_HEADER(<header_name>) it is not possible to see the actual response code. However, Asterisk 1.8 allows to read SIP response codes in the dialplan with ${HASH(SIP_CAUSE,<channel-name>)}. Additionally make sure you are using the destination channel, not the source channel. Asterisk 1.8 also comes with a 'use_q850_reason' configuration option for generating and parsing, if available, "Reason: Q.850;cause=<cause code>" for better passing PRI/SS7 cause codes via SIP.
There should really be a FAIL result so that it is possible to distinguish between "CONGESTION" and a genuine call setup failure.
Consider the following situations:-
CONGESTION "Congestion" is somewhat misleading. Unfortunately at this time (2007-05-17), Dial() returns DIALSTATUS=CONGESTION for pretty much every call setup problem. The reason for this is that Dial() is used for multiple protocols (Zap,SIP,IAX etc.) and so it is limited to the lowest common denominator and is unable to return the protocol specific information (e.g., SIP 404 response) .
There is also currently no way to obtain the SIP response in the dialplan, even though it is reported on the debug console (if debug level >3). Even though one can see every other SIP header with ${SIP_HEADER(<header_name>) it is not possible to see the actual response code. However, Asterisk 1.8 allows to read SIP response codes in the dialplan with ${HASH(SIP_CAUSE,<channel-name>)}. Additionally make sure you are using the destination channel, not the source channel. Asterisk 1.8 also comes with a 'use_q850_reason' configuration option for generating and parsing, if available, "Reason: Q.850;cause=<cause code>" for better passing PRI/SS7 cause codes via SIP.
There should really be a FAIL result so that it is possible to distinguish between "CONGESTION" and a genuine call setup failure.
Consider the following situations:-