<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:11pt; color:black">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:11pt; color:black"><br>
<br>
Sent from my Android phone using TouchDown (www.nitrodesk.com)<br>
<br>
<span style="color:black">-----Original Message----- <br>
<b>From:</b> asterisk-dev-request@lists.digium.com [asterisk-dev-request@lists.digium.com]<br>
<b>Received:</b> Wednesday, 05 Sep 2012, 17:05<br>
<b>To:</b> asterisk-dev@lists.digium.com [asterisk-dev@lists.digium.com]<br>
<b>Subject:</b> asterisk-dev Digest, Vol 98, Issue 15<br>
<br>
</span></span></div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Send asterisk-dev mailing list submissions to<br>
asterisk-dev@lists.digium.com<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
asterisk-dev-request@lists.digium.com<br>
<br>
You can reach the person managing the list at<br>
asterisk-dev-owner@lists.digium.com<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of asterisk-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: ATXfer broken, DTMF works but * disconnects wrong leg<br>
(Matt Riddell)<br>
2. Re: [Code Review]: Changes from Mantis ID 13495 in trunk. (KNK)<br>
3. Re: [Code Review]: Changes from Mantis ID 13495 in trunk.<br>
(rmudgett)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 5 Sep 2012 11:52:15 -0400<br>
From: Matt Riddell <lists@venturevoip.com><br>
Subject: Re: [asterisk-dev] ATXfer broken, DTMF works but *<br>
disconnects wrong leg<br>
To: Asterisk Developers Mailing List <asterisk-dev@lists.digium.com><br>
Message-ID: <B81AE9E2-4F0D-4B0C-BB5A-A79BD0E35FC6@venturevoip.com><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On 5/09/2012, at 11:28 AM, Richard Mudgett <rmudgett@digium.com> wrote:<br>
>> As per the message the Manager Command ATXfer doesn't seem to work<br>
>> yet sending DTMF to do the same does (I wonder if it's the channel<br>
>> it's operating on).<br>
>> <br>
>> <br>
>> I don't care about that so much as I can work around that by using<br>
>> DTMF instead.<br>
>> <br>
>> <br>
>> The problem is that sending a * for disconnect is disconnecting the<br>
>> person doing the transfer rather than aborting the transfer.<br>
>> <br>
>> <br>
>> If someone could point me in the right direction I'll have a look at<br>
>> it.<br>
> <br>
> The code handling the DTMF attended transfer feature and other DTMF<br>
> features is in features.c.<br>
<br>
<br>
Ok, cool, I was already in there for some other stuff so I'll just see if I can figure out where the disconnect is happening.<br>
<br>
--<br>
Cheers,<br>
<br>
Matt Riddell<br>
_______________________________________________<br>
<br>
<a href="http://www.venturevoip.com/news.php">http://www.venturevoip.com/news.php</a> (Daily Asterisk News)<br>
<a href="http://www.venturevoip.com/pabx_on_disk.php">http://www.venturevoip.com/pabx_on_disk.php</a> (PABX on a Disk)<br>
<a href="http://www.venturevoip.com/exchange.php">http://www.venturevoip.com/exchange.php</a> (Full ITSP Solution)<br>
<a href="http://www.venturevoip.com/cc.php">http://www.venturevoip.com/cc.php</a> (Call Centre Solutions)<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 05 Sep 2012 16:00:46 -0000<br>
From: "KNK" <reviewboard@asterisk.org><br>
Subject: Re: [asterisk-dev] [Code Review]: Changes from Mantis ID<br>
13495 in trunk.<br>
To: "KNK" <reviewboard@asterisk.org>, "Asterisk Developers"<br>
<asterisk-dev@lists.digium.com>, kkovachev@mail.varna.net,<br>
rmudgett@digium.com<br>
Message-ID: <20120905160046.30948.52649@hotblack.digium.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
<br>
> On Aug. 31, 2012, 3:18 p.m., rmudgett wrote:<br>
> > trunk/configs/ss7.timers.sample, line 41<br>
> > <<a href="https://reviewboard.asterisk.org/r/1676/diff/14/?file=31128#file31128line41">https://reviewboard.asterisk.org/r/1676/diff/14/?file=31128#file31128line41</a>><br>
> ><br>
> > I cannot find the definition for this timer in ITU. It is really the overlap digit timeout and must always be defined (Even for ANSI).<br>
> > <br>
> > If your dialplan has extension 100 and extension 1000 and an incoming call calls 100, then the call will not go through and the channel will get stuck in the allocated state. (p->call_level = SIG_SS7_CALL_LEVEL_ALLOCATED)<br>
> > <br>
> > Also if the incoming call hangs up before this timer expires, the channel will be stuck because the call was never passed to Asterisk core.<br>
> > <br>
> > Another incoming call on this circuit will clear this stuck condition if it gets passed to the Asterisk core. However, it will have an assertion failure in the IAM processing about the channel not being idle.<br>
> > ast_assert(!p->owner && p->call_level == SIG_SS7_CALL_LEVEL_IDLE)<br>
> <br>
> KNK wrote:<br>
> ITU-T Q.764 2.1.2.1 d) and 2.1.4.8 e) then 4-6sec timer value defined in table A.1 and we should send ACM on expire, but in ANSI T1.113 there is a Note that 'Timer is not specified for U. S. networks.'<br>
> <br>
> So the assert should be changed to pass both states SIG_SS7_CALL_LEVEL_IDLE and SIG_SS7_CALL_LEVEL_ALLOCATED or i misunderstood?<br>
><br>
> <br>
> rmudgett wrote:<br>
> There are two issues here:<br>
> <br>
> 1) I take it the SAM message is not supported by ANSI since T10 is not specified. With no T10 specified, then ss7_match_extension() should be changed to not call isup_start_digittimeout() if configured for ANSI since that timer is not specified for US
networks. The called number must either match or not match an extension.<br>
> <br>
> 2) There is a glare problem at the root of this assertion failure. It is not easy to explain because it involves a long chain of events. Since libss7 now handles glare resolution, libss7 needs to be informed about a pending outgoing call when chan_dahdi
allocates a channel for it.<br>
> <br>
> ast_request() allocates resources for an outgoing call.<br>
> ast_call() initiates the outgoing call.<br>
> ast_hangup() can be called on a channel at any time after ast_request() to destroy the created channel.<br>
> <br>
> Currently libss7 doesn't know about a pending outgoing call until the ast_call() happens. If an incoming call happens between the ast_request() and the ast_call(), the glare is not handled and the two calls step on each other.<br>
><br>
> <br>
> KNK wrote:<br>
> 1) About T10 - the original code had it as DIGITTIMEOUT timer used for both ITU and ANSI. As T10 on my understanding has the similar functionality i have renamed it to T10 which led to the confusion, because T10 is not defined for ANSI ... after digging
(googling) a bit more i've found that 'In North America, enbloc signaling is always used', so it is OK to leave it as T10 and will fix ss7_match_extension() to send REL if T10 is not defined or ANSI (just to be safe) ... isup_start_digittimeout() in libss7
should be changed to non-void.<br>
> Actually libss7 is unable to use overlap dialing out and i have not tested dialing in too - that functionality deserves some attention later.<br>
> <br>
> 2) the code removed after v6 <a href="https://reviewboard.asterisk.org/r/1676/diff/6/?file=29257#file29257line1461">
https://reviewboard.asterisk.org/r/1676/diff/6/?file=29257#file29257line1461</a>, should be restored then - dropping both calls is the only way out of this situation as we do not have an isup_call yet and no way to inform libss7<br>
<br>
Just an idea about 2) ... what if we do the opposite i.e. add a callback in Asterisk, so libss7 can check for dual seizure from isup_event_iam(). The callback can then simply check for call_level == SIG_SS7_CALL_LEVEL_IDLE<br>
<br>
<br>
- KNK<br>
<br>
<br>
-----------------------------------------------------------<br>
This is an automatically generated e-mail. To reply, visit:<br>
<a href="https://reviewboard.asterisk.org/r/1676/#review6994">https://reviewboard.asterisk.org/r/1676/#review6994</a><br>
-----------------------------------------------------------<br>
<br>
<br>
On Aug. 31, 2012, 10:36 a.m., KNK wrote:<br>
> <br>
> -----------------------------------------------------------<br>
> This is an automatically generated e-mail. To reply, visit:<br>
> <a href="https://reviewboard.asterisk.org/r/1676/">https://reviewboard.asterisk.org/r/1676/</a><br>
> -----------------------------------------------------------<br>
> <br>
> (Updated Aug. 31, 2012, 10:36 a.m.)<br>
> <br>
> <br>
> Review request for Asterisk Developers.<br>
> <br>
> <br>
> Summary<br>
> -------<br>
> <br>
> chan_dahdi / sig_ss7 part of changes<br>
> <br>
> <br>
> This addresses bug SS7-27.<br>
> <a href="https://issues.asterisk.org/jira/browse/SS7-27">https://issues.asterisk.org/jira/browse/SS7-27</a><br>
> <br>
> <br>
> Diffs<br>
> -----<br>
> <br>
> trunk/channels/chan_dahdi.c 372115 <br>
> trunk/channels/sig_ss7.h 372115 <br>
> trunk/channels/sig_ss7.c 372115 <br>
> trunk/configs/chan_dahdi.conf.sample 372115 <br>
> trunk/configs/ss7.timers.sample PRE-CREATION <br>
> trunk/configure.ac 372115 <br>
> <br>
> Diff: <a href="https://reviewboard.asterisk.org/r/1676/diff">https://reviewboard.asterisk.org/r/1676/diff</a><br>
> <br>
> <br>
> Testing<br>
> -------<br>
> <br>
> compiles, link setup, cli commands, bassic calls, connected line and redirection.<br>
> <br>
> <br>
> Thanks,<br>
> <br>
> KNK<br>
> <br>
><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.digium.com/pipermail/asterisk-dev/attachments/20120905/6be19d4e/attachment-0001.htm">http://lists.digium.com/pipermail/asterisk-dev/attachments/20120905/6be19d4e/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 05 Sep 2012 16:05:12 -0000<br>
From: "rmudgett" <reviewboard@asterisk.org><br>
Subject: Re: [asterisk-dev] [Code Review]: Changes from Mantis ID<br>
13495 in trunk.<br>
To: "rmudgett" <reviewboard@asterisk.org>, "Asterisk Developers"<br>
<asterisk-dev@lists.digium.com>, kkovachev@mail.varna.net,<br>
rmudgett@digium.com<br>
Message-ID: <20120905160512.31549.39117@hotblack.digium.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
<br>
> On Aug. 31, 2012, 3:18 p.m., rmudgett wrote:<br>
> > trunk/configs/ss7.timers.sample, line 41<br>
> > <<a href="https://reviewboard.asterisk.org/r/1676/diff/14/?file=31128#file31128line41">https://reviewboard.asterisk.org/r/1676/diff/14/?file=31128#file31128line41</a>><br>
> ><br>
> > I cannot find the definition for this timer in ITU. It is really the overlap digit timeout and must always be defined (Even for ANSI).<br>
> > <br>
> > If your dialplan has extension 100 and extension 1000 and an incoming call calls 100, then the call will not go through and the channel will get stuck in the allocated state. (p->call_level = SIG_SS7_CALL_LEVEL_ALLOCATED)<br>
> > <br>
> > Also if the incoming call hangs up before this timer expires, the channel will be stuck because the call was never passed to Asterisk core.<br>
> > <br>
> > Another incoming call on this circuit will clear this stuck condition if it gets passed to the Asterisk core. However, it will have an assertion failure in the IAM processing about the channel not being idle.<br>
> > ast_assert(!p->owner && p->call_level == SIG_SS7_CALL_LEVEL_IDLE)<br>
> <br>
> KNK wrote:<br>
> ITU-T Q.764 2.1.2.1 d) and 2.1.4.8 e) then 4-6sec timer value defined in table A.1 and we should send ACM on expire, but in ANSI T1.113 there is a Note that 'Timer is not specified for U. S. networks.'<br>
> <br>
> So the assert should be changed to pass both states SIG_SS7_CALL_LEVEL_IDLE and SIG_SS7_CALL_LEVEL_ALLOCATED or i misunderstood?<br>
><br>
> <br>
> rmudgett wrote:<br>
> There are two issues here:<br>
> <br>
> 1) I take it the SAM message is not supported by ANSI since T10 is not specified. With no T10 specified, then ss7_match_extension() should be changed to not call isup_start_digittimeout() if configured for ANSI since that timer is not specified for US
networks. The called number must either match or not match an extension.<br>
> <br>
> 2) There is a glare problem at the root of this assertion failure. It is not easy to explain because it involves a long chain of events. Since libss7 now handles glare resolution, libss7 needs to be informed about a pending outgoing call when chan_dahdi
allocates a channel for it.<br>
> <br>
> ast_request() allocates resources for an outgoing call.<br>
> ast_call() initiates the outgoing call.<br>
> ast_hangup() can be called on a channel at any time after ast_request() to destroy the created channel.<br>
> <br>
> Currently libss7 doesn't know about a pending outgoing call until the ast_call() happens. If an incoming call happens between the ast_request() and the ast_call(), the glare is not handled and the two calls step on each other.<br>
><br>
> <br>
> KNK wrote:<br>
> 1) About T10 - the original code had it as DIGITTIMEOUT timer used for both ITU and ANSI. As T10 on my understanding has the similar functionality i have renamed it to T10 which led to the confusion, because T10 is not defined for ANSI ... after digging
(googling) a bit more i've found that 'In North America, enbloc signaling is always used', so it is OK to leave it as T10 and will fix ss7_match_extension() to send REL if T10 is not defined or ANSI (just to be safe) ... isup_start_digittimeout() in libss7
should be changed to non-void.<br>
> Actually libss7 is unable to use overlap dialing out and i have not tested dialing in too - that functionality deserves some attention later.<br>
> <br>
> 2) the code removed after v6 <a href="https://reviewboard.asterisk.org/r/1676/diff/6/?file=29257#file29257line1461">
https://reviewboard.asterisk.org/r/1676/diff/6/?file=29257#file29257line1461</a>, should be restored then - dropping both calls is the only way out of this situation as we do not have an isup_call yet and no way to inform libss7<br>
> <br>
> KNK wrote:<br>
> Just an idea about 2) ... what if we do the opposite i.e. add a callback in Asterisk, so libss7 can check for dual seizure from isup_event_iam(). The callback can then simply check for call_level == SIG_SS7_CALL_LEVEL_IDLE<br>
<br>
2) Yes. I think that would be best. The architecture of chan_dahdi handles glare poorly for anything but analog. The problem is mainly because chan_dahdi assigns the media to the call before the channel protocols have a chance to negotiate for it.<br>
<br>
<br>
- rmudgett<br>
<br>
<br>
-----------------------------------------------------------<br>
This is an automatically generated e-mail. To reply, visit:<br>
<a href="https://reviewboard.asterisk.org/r/1676/#review6994">https://reviewboard.asterisk.org/r/1676/#review6994</a><br>
-----------------------------------------------------------<br>
<br>
<br>
On Aug. 31, 2012, 10:36 a.m., KNK wrote:<br>
> <br>
> -----------------------------------------------------------<br>
> This is an automatically generated e-mail. To reply, visit:<br>
> <a href="https://reviewboard.asterisk.org/r/1676/">https://reviewboard.asterisk.org/r/1676/</a><br>
> -----------------------------------------------------------<br>
> <br>
> (Updated Aug. 31, 2012, 10:36 a.m.)<br>
> <br>
> <br>
> Review request for Asterisk Developers.<br>
> <br>
> <br>
> Summary<br>
> -------<br>
> <br>
> chan_dahdi / sig_ss7 part of changes<br>
> <br>
> <br>
> This addresses bug SS7-27.<br>
> <a href="https://issues.asterisk.org/jira/browse/SS7-27">https://issues.asterisk.org/jira/browse/SS7-27</a><br>
> <br>
> <br>
> Diffs<br>
> -----<br>
> <br>
> trunk/channels/chan_dahdi.c 372115 <br>
> trunk/channels/sig_ss7.h 372115 <br>
> trunk/channels/sig_ss7.c 372115 <br>
> trunk/configs/chan_dahdi.conf.sample 372115 <br>
> trunk/configs/ss7.timers.sample PRE-CREATION <br>
> trunk/configure.ac 372115 <br>
> <br>
> Diff: <a href="https://reviewboard.asterisk.org/r/1676/diff">https://reviewboard.asterisk.org/r/1676/diff</a><br>
> <br>
> <br>
> Testing<br>
> -------<br>
> <br>
> compiles, link setup, cli commands, bassic calls, connected line and redirection.<br>
> <br>
> <br>
> Thanks,<br>
> <br>
> KNK<br>
> <br>
><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.digium.com/pipermail/asterisk-dev/attachments/20120905/0fe6655e/attachment.htm">http://lists.digium.com/pipermail/asterisk-dev/attachments/20120905/0fe6655e/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br>
<br>
AstriCon 2010 - October 26-28 Washington, DC<br>
Put in your talk proposal: <a href="http://www.bit.ly/speak-astricon2010">http://www.bit.ly/speak-astricon2010</a><br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
<br>
End of asterisk-dev Digest, Vol 98, Issue 15<br>
********************************************<br>
<br>
______________________________________________________________________<br>
This email has been scanned by the Symantec Email Security.cloud service.<br>
For more information please visit <a href="http://www.symanteccloud.com">http://www.symanteccloud.com</a><br>
______________________________________________________________________<br>
</div>
</span></font>
</body>
</html>