[asterisk-dev] asterisk-dev Digest, Vol 98, Issue 15
Ahsan Masood
ahsan at telappliant.com
Wed Sep 5 12:56:17 CDT 2012
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-----Original Message-----
From: asterisk-dev-request at lists.digium.com [asterisk-dev-request at lists.digium.com]
Received: Wednesday, 05 Sep 2012, 17:05
To: asterisk-dev at lists.digium.com [asterisk-dev at lists.digium.com]
Subject: asterisk-dev Digest, Vol 98, Issue 15
Send asterisk-dev mailing list submissions to
asterisk-dev at lists.digium.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.digium.com/mailman/listinfo/asterisk-dev
or, via email, send a message with subject or body 'help' to
asterisk-dev-request at lists.digium.com
You can reach the person managing the list at
asterisk-dev-owner at lists.digium.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of asterisk-dev digest..."
Today's Topics:
1. Re: ATXfer broken, DTMF works but * disconnects wrong leg
(Matt Riddell)
2. Re: [Code Review]: Changes from Mantis ID 13495 in trunk. (KNK)
3. Re: [Code Review]: Changes from Mantis ID 13495 in trunk.
(rmudgett)
----------------------------------------------------------------------
Message: 1
Date: Wed, 5 Sep 2012 11:52:15 -0400
From: Matt Riddell <lists at venturevoip.com>
Subject: Re: [asterisk-dev] ATXfer broken, DTMF works but *
disconnects wrong leg
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <B81AE9E2-4F0D-4B0C-BB5A-A79BD0E35FC6 at venturevoip.com>
Content-Type: text/plain; charset=us-ascii
On 5/09/2012, at 11:28 AM, Richard Mudgett <rmudgett at digium.com> wrote:
>> As per the message the Manager Command ATXfer doesn't seem to work
>> yet sending DTMF to do the same does (I wonder if it's the channel
>> it's operating on).
>>
>>
>> I don't care about that so much as I can work around that by using
>> DTMF instead.
>>
>>
>> The problem is that sending a * for disconnect is disconnecting the
>> person doing the transfer rather than aborting the transfer.
>>
>>
>> If someone could point me in the right direction I'll have a look at
>> it.
>
> The code handling the DTMF attended transfer feature and other DTMF
> features is in features.c.
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.
--
Cheers,
Matt Riddell
_______________________________________________
http://www.venturevoip.com/news.php (Daily Asterisk News)
http://www.venturevoip.com/pabx_on_disk.php (PABX on a Disk)
http://www.venturevoip.com/exchange.php (Full ITSP Solution)
http://www.venturevoip.com/cc.php (Call Centre Solutions)
------------------------------
Message: 2
Date: Wed, 05 Sep 2012 16:00:46 -0000
From: "KNK" <reviewboard at asterisk.org>
Subject: Re: [asterisk-dev] [Code Review]: Changes from Mantis ID
13495 in trunk.
To: "KNK" <reviewboard at asterisk.org>, "Asterisk Developers"
<asterisk-dev at lists.digium.com>, kkovachev at mail.varna.net,
rmudgett at digium.com
Message-ID: <20120905160046.30948.52649 at hotblack.digium.com>
Content-Type: text/plain; charset="utf-8"
> On Aug. 31, 2012, 3:18 p.m., rmudgett wrote:
> > trunk/configs/ss7.timers.sample, line 41
> > <https://reviewboard.asterisk.org/r/1676/diff/14/?file=31128#file31128line41>
> >
> > 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).
> >
> > 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)
> >
> > 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.
> >
> > 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.
> > ast_assert(!p->owner && p->call_level == SIG_SS7_CALL_LEVEL_IDLE)
>
> KNK wrote:
> 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.'
>
> So the assert should be changed to pass both states SIG_SS7_CALL_LEVEL_IDLE and SIG_SS7_CALL_LEVEL_ALLOCATED or i misunderstood?
>
>
> rmudgett wrote:
> There are two issues here:
>
> 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.
>
> 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.
>
> ast_request() allocates resources for an outgoing call.
> ast_call() initiates the outgoing call.
> ast_hangup() can be called on a channel at any time after ast_request() to destroy the created channel.
>
> 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.
>
>
> KNK wrote:
> 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.
> Actually libss7 is unable to use overlap dialing out and i have not tested dialing in too - that functionality deserves some attention later.
>
> 2) the code removed after v6 https://reviewboard.asterisk.org/r/1676/diff/6/?file=29257#file29257line1461, 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
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
- KNK
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1676/#review6994
-----------------------------------------------------------
On Aug. 31, 2012, 10:36 a.m., KNK wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1676/
> -----------------------------------------------------------
>
> (Updated Aug. 31, 2012, 10:36 a.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Summary
> -------
>
> chan_dahdi / sig_ss7 part of changes
>
>
> This addresses bug SS7-27.
> https://issues.asterisk.org/jira/browse/SS7-27
>
>
> Diffs
> -----
>
> trunk/channels/chan_dahdi.c 372115
> trunk/channels/sig_ss7.h 372115
> trunk/channels/sig_ss7.c 372115
> trunk/configs/chan_dahdi.conf.sample 372115
> trunk/configs/ss7.timers.sample PRE-CREATION
> trunk/configure.ac 372115
>
> Diff: https://reviewboard.asterisk.org/r/1676/diff
>
>
> Testing
> -------
>
> compiles, link setup, cli commands, bassic calls, connected line and redirection.
>
>
> Thanks,
>
> KNK
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120905/6be19d4e/attachment-0001.htm>
------------------------------
Message: 3
Date: Wed, 05 Sep 2012 16:05:12 -0000
From: "rmudgett" <reviewboard at asterisk.org>
Subject: Re: [asterisk-dev] [Code Review]: Changes from Mantis ID
13495 in trunk.
To: "rmudgett" <reviewboard at asterisk.org>, "Asterisk Developers"
<asterisk-dev at lists.digium.com>, kkovachev at mail.varna.net,
rmudgett at digium.com
Message-ID: <20120905160512.31549.39117 at hotblack.digium.com>
Content-Type: text/plain; charset="utf-8"
> On Aug. 31, 2012, 3:18 p.m., rmudgett wrote:
> > trunk/configs/ss7.timers.sample, line 41
> > <https://reviewboard.asterisk.org/r/1676/diff/14/?file=31128#file31128line41>
> >
> > 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).
> >
> > 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)
> >
> > 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.
> >
> > 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.
> > ast_assert(!p->owner && p->call_level == SIG_SS7_CALL_LEVEL_IDLE)
>
> KNK wrote:
> 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.'
>
> So the assert should be changed to pass both states SIG_SS7_CALL_LEVEL_IDLE and SIG_SS7_CALL_LEVEL_ALLOCATED or i misunderstood?
>
>
> rmudgett wrote:
> There are two issues here:
>
> 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.
>
> 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.
>
> ast_request() allocates resources for an outgoing call.
> ast_call() initiates the outgoing call.
> ast_hangup() can be called on a channel at any time after ast_request() to destroy the created channel.
>
> 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.
>
>
> KNK wrote:
> 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.
> Actually libss7 is unable to use overlap dialing out and i have not tested dialing in too - that functionality deserves some attention later.
>
> 2) the code removed after v6 https://reviewboard.asterisk.org/r/1676/diff/6/?file=29257#file29257line1461, 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
>
> KNK wrote:
> 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
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.
- rmudgett
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1676/#review6994
-----------------------------------------------------------
On Aug. 31, 2012, 10:36 a.m., KNK wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1676/
> -----------------------------------------------------------
>
> (Updated Aug. 31, 2012, 10:36 a.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Summary
> -------
>
> chan_dahdi / sig_ss7 part of changes
>
>
> This addresses bug SS7-27.
> https://issues.asterisk.org/jira/browse/SS7-27
>
>
> Diffs
> -----
>
> trunk/channels/chan_dahdi.c 372115
> trunk/channels/sig_ss7.h 372115
> trunk/channels/sig_ss7.c 372115
> trunk/configs/chan_dahdi.conf.sample 372115
> trunk/configs/ss7.timers.sample PRE-CREATION
> trunk/configure.ac 372115
>
> Diff: https://reviewboard.asterisk.org/r/1676/diff
>
>
> Testing
> -------
>
> compiles, link setup, cli commands, bassic calls, connected line and redirection.
>
>
> Thanks,
>
> KNK
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120905/0fe6655e/attachment.htm>
------------------------------
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
AstriCon 2010 - October 26-28 Washington, DC
Put in your talk proposal: http://www.bit.ly/speak-astricon2010
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
End of asterisk-dev Digest, Vol 98, Issue 15
********************************************
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120905/557d6da9/attachment-0001.htm>
More information about the asterisk-dev
mailing list