I was wondering how SIGTRAN/SS7oIP can fit into our currently 100% SIP model. We are looking to interconnect with the PSTN world, and our supplier has given us a few options. We can either do this over traditional PRIs, A-Links or the SS7IP new.
I am really interested in SIGTRAN, and was wondering how some of you have integrated it into your architecture. Can Asterisk handle SS70IP or do we have to put a yate or squire server at the end of that connection.
* You are viewing Posts Tagged ‘PSTN’
Hello. i am running debian 6 with asterisk 11.4. The system has exim4 to send to email the voicemails. i would like to get rid of the analog fax machine and use asterisk to send/receive faxes. I do have a PSTN line with a SPA3102 adapter to interface it to asterisk. The number of the PSTN line is dedicated to faxing only. So i would like to:
-receive faxes to asterisk and then send it as PDFs to an email address
-Send from my PC a fax directly.
is there any guide on how to do that since i got lost with all of it?
We have several Asterik boxes that are connected to PSTN using PRI cards and they are interconnected using IAX2 trunks so that incoming calls are delivered from PSTN to the servers they belong to.
In past we were using asterisk 1.4 on the server that is receiving IAX
connections and everything worked as expected. Recently, we have switched to a newer box with asterisk 1.8.22 and then we began to experience sometimes a strange problem:
At some point of time, incoming IAX connections begin to get refused by the server and we get the following messages in the logs:
WARNING[XXXX] chan_iax2.c: Too much delay in IAX2 calltoken timestamp from address X.X.X.X
where X.X.X.X is the IP of the PSTN->IAX gateways and all the incoming calls start to be rejected.
Direct PSTN calls (both incoming and outgoing) to the same server work OK. The only solution that helps is to kill the asterisk and restart it.
All the servers are connected to the same LAN segment, with gigabit switch, there is no problems with the network. No packet loss.
There’s already bug report present with very similar issue, but it is
“suspended” and, like stated there, the problem is very hard to reproduce.
What I have is:
* Asterisk 188.8.131.52~dfsg-1ubuntu1,
* SPA112 ATA with analog fax in 1-st FXS port connected,
* SIP trunk with provider supporting T.38.
My network looks like this:
* spa112 (192.168.33.200/24) and Asterisk (192.168.5.253/24) in neighbouring LANs,
* Asterisk connects to the provider (184.108.40.206) via router
(220.127.116.11). Router has full DNAT to Asterisk server.
* The fax from SPA112 to Asterisk cmd ReceiveFax works well,
* The fax from Asterisk cmd SendFax to PSTN fax works well,
* However, the fax from SPA112 to PSTN fax doesn’t work. Using udptl debug, I can see packets between Asterisk and both sides (SPA112 and PSTN fax) but it seems that faxes can’t agree how to send image.
tcpenable=yes videosupport=yes transport=udp,tcp dtmfmode=rfc2833
qualify=yes directmedia=no allowguest=no alwaysauthreject=yes rtcachefriends=yes rtupdate=no callcounter=yes t38pt_udptl=yes,redundancy,maxdatagram 0
t38pt_rtp=no t38pt_tcp=no ignoresdpversion=yes disallow=all allow=alaw allow=ulaw externip
At first should be useful to post your message at firstname.lastname@example.org group. By the other way let me advice, to make an explained detail of your problem as;
Asterisk version Openr2 version Configurations files Dialplan dahdi pattern detail Detail of the call process (inbound or outbound call failed?)
In case of outbound call failed extension dial wait time of the call process (waiting for ringback tone, busy, reorder, silence etc)
call trace log (for better collect information, you could move or delete old data log on /var/log asterisk/…..)
In case of inbound call failed, it could be possible with call log and monitoring bit CAS signalling
Based on your explanation and information could let you know the possible reason of the weird issue.
By the other way, let me explain when dahdi restart, it make hardware reset, therefore will stop card control software and restart again, these will cause lost frame connection between you box and PSTN, and call process, etc. When dahdi restart again it recover frame between both side and set CAS control channel according to dahdi parameters setting on system.conf These is for preventing to let to PSTN start call handler process during asterisk starting process or stop. Another point it seems on your log information a call have been answered, so it seems is working.
PD: 0×00 it doesn’t mean idle state (it mean force release)
Mc GRATH Ricardo E-Mail email@example.com