Yes you understood now. Importantly BEFORE the dial happens. It could be that
you play some courtesy message or query some portability DB or do whatever
other manipulations on the extension before entering the progress, however in
your simple dialplan, it would fit best on top. I recommend you to make use of
Noop functions since they save your life once you have 32 (!) E1 live traffic
with the poor logging facility Asterisk offers.
exten => _DPC5118X.,1,NoOP(OPC4607 calling DPC5118)
exten => _DPC5118X.,n,Progress()
exten => _DPC5118X.,n,NoOp(dump NUM ${CALLERID(num)})
exten => _DPC5118X.,n,NoOp(dump DNID ${CALLERID(dnid)})
exten => _DPC5118X.,n,NoOp(dump RDNIS ${CALLERID(rdnis)})
exten => _DPC5118X.,n,NoOp(dump PRES ${CALLERID(pres)})
exten => _DPC5118X.,n,Dial(SS7/set2/${EXTEN:7})
I don’t know LibSS7 myself (happy user of chan_SS7), but the ‘Dial/DAHDI’ seems
weird since Dial is the correct application within Asterisk but the channel
isn’t DAHDI, is it? Well, maybe it is. Apparently it works for you except for
the inband progress tones which we are going to fix here.
A SIP trace is always best, because that is a clear thing (as opposed to
Asterisks logging). Use this courtesy command:
For signaling only: tcpdump -w /tmp/trace_port5060_`(date -u
"+%Y%m%dT%H%M%S")`.pcap -s 65535 udp port 5060 -s 65535
For everything: tcpdump -w /tmp/trace-full_`(date -u "+%Y%m%dT%H%M%S")`.pcap -s
65535 udp -s 65535
To read the trace, use Wireshark.
Oh, did I already say that Asterisk logging leaves room for desire (at least
from the perspective of a telco engineer trying to understand which channel in
which thread changes what state at what time, printed to a log rounded to a the
millisecond)?
You should give chan_SS7 another go and buy support. If Anders cannot
understand your problem and fix it (and acknowledge that it is related to
chan_SS7 and not to third party software, I bet you are out of luck pretty much
everywhere.
Ever considered looking into buying a telco grade Dialogic/Cantata mediagateway
with SS7 support, probably supporting all your need in a single 1U chassis?
Works for us with no babysitting required. Teles might be an even lower cost
alternative, what I have heard from peers.
With your straight forward requirement, you don’t need all the beautiful
Asterisk features (and hassles) and with your knowledge you WILL NEED support.
But be careful, you might become redundant with a solution that “just works”.
Regards, Florian
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Nyamul Hassan
Gesendet: Mittwoch, 22. Juni 2011 13:20
An: [email protected]
Betreff: Re: [asterisk-ss7] Asterisk 1.8.4.2 + LibSS7 1.0.2 : Early Media
Problem
Thank you Florain, for your reply. My answers are inline.
On Wed, Jun 22, 2011 at 17:08, <[email protected]> wrote:
Hassan, I think I have a contribution to your problem:
As of Release 1.6, you need to make an explicit
exten => 1234,n,Progress()
Oh, did not know that. So, I need to put this at the top of the dialplan,
before I put the "dialplan", right?
My current dialplan is:
[ss7out]
exten => _919.,1,Dial(DAHDI/g1/${EXTEN:2})
exten => _919.,n,Hangup()
So, change this to:
[ss7out]
exten => _919.,1,Progress()
exten => _919.,n,Dial(DAHDI/g1/${EXTEN:2})
exten => _919.,n,Hangup()
else Asterisk will not proceed using SIP/183 with SDP. Can you show the
signaling data of the SIP session? It would help to understand what call vector
you are having issues with since the routing (aka dialplan) has different
requirements on an incoming (SS7->SIP), respectively outgoing call (SIP->SS7).
Can you tell me what data you want? Do I need to do a SIP Trace? Or SS7
Trace? I've never done the trace on LibSS7 earlier. Which command do I need
to run?
Regards
HASSAN
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-ss7
