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: asterisk-ss7-bounces at lists.digium.com [mailto:asterisk-ss7-bounces at lists.digium.com] Im Auftrag von Nyamul Hassan
Gesendet: Mittwoch, 22. Juni 2011 13:20
An: asterisk-ss7 at lists.digium.com
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, <florian at gruendler.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110622/e35dac89/attachment-0001.htm>
|