Re: [asterisk-dev] ISDN Userfield UUI has a length constraint?

2014-06-16 Thread Richard Mudgett 
On Mon, Jun 16, 2014 at 3:03 PM, Yves A.  wrote:

> Hello List,
>
> I made the changes in the q931.c sourcefile and got rid of the 35
> character constraint.
> thanks for your attention.
> yves
>
> Am 16.06.2014 15:23, schrieb Yves A.:
>
>  seems, I found the right place by myself... no wonder I could not find it
>> in asterisk sources
>> the constraint is located in the sources of libpri I will change
>> that, recompile and post feedback here...
>>
>> thanks anyways,
>> yves
>>
>> Am 16.06.2014 14:57, schrieb Yves A.:
>>
>>> Hi,
>>>
>>> I am using the Q931 / ISDN USER-USER-INFO field for transferring data
>>> between the caller and the called party.
>>> This works fine as long as the information does not exceed 35
>>> characters...
>>> Unfortunately sometimes I need more space and due to the Q931 Specs I
>>> think there should be space for max. 128 octets (bytes/characters)...
>>> Can someone point me to the place in the sources where I can check and
>>> adopt this?
>>> I have tested this on an asterisk 11.3 and on an asterisk 1.6.2.24
>>> both show the same limit of 35 characters...
>>>
>>
That restriction has been there since the feature was put into the code.
This would be the reason for the 35 character restriction:

ITU Q.931 Section 4.5.30:
{quote}
In USER INFORMATION messages sent in association with a circuit-mode
connection, the User-
user information element has a network dependent maximum size of 35 or 131
octets. For USER
INFORMATION messages sent in a temporary or permanent user-user signalling
connection, the
user information field contained inside this information element has a
maximum size equal to the
maximum size of messages defined in clause 3, that is 260 octets.
{quote}

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] libpri 1.4.15 Now Available

2014-06-16 Thread Yves A. 

This is really funny... 5 Secs after I applied my patch...
Maybe the development team of libpri could remove the 35 char maxlength 
constraint when using USERUSERINFO
in the next release so I don´t have to patch it always... Or is there a 
specific reason for it?


regards,
yves

Am 16.06.2014 23:01, schrieb Asterisk Development Team:

The Asterisk Development Team has announced the release of libpri 1.4.15.
This release is available for immediate download at
http://downloads.asterisk.org/pub/telephony/libpri

The release of libpri 1.4.15 resolves several issues reported by the
community and would not have been possible without your participation.

Thank you!

The following are the issues resolved in this release:

* --- Fix hole in layer2_persistence option for TE PTMP links.
   (Closes issue LIBPRI-72.  Reported by: Trey Blancher)

* --- Make TE-PTP mode respond to MDL TEI check requests.
   (PRI-165 Reported by: Denis Alberto Martinez)

* --- Add control of inband audio progress indication ie to the
   SETUP_ACKNOWLEDGE message.
   (Closes issue AST-1338.  Reported by: Tyler Stewart)

* --- Adjust T202 default value to the minimum.
   (Closes issue PRI-171.  Reported by: dcolombo)

For a full list of changes and descriptions of the chagnes in this
release, please see the ChangeLog:

http://downloads.asterisk.org/pub/telephony/libpri/ChangeLog-1.4.15

Thank you for your continued support of Asterisk!





--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] ISDN Userfield UUI has a length constraint?

2014-06-16 Thread Yves A. 

Hello List,

I made the changes in the q931.c sourcefile and got rid of the 35 
character constraint.

thanks for your attention.
yves

Am 16.06.2014 15:23, schrieb Yves A.:
seems, I found the right place by myself... no wonder I could not find 
it in asterisk sources
the constraint is located in the sources of libpri I will change 
that, recompile and post feedback here...


thanks anyways,
yves

Am 16.06.2014 14:57, schrieb Yves A.:

Hi,

I am using the Q931 / ISDN USER-USER-INFO field for transferring data 
between the caller and the called party.
This works fine as long as the information does not exceed 35 
characters...
Unfortunately sometimes I need more space and due to the Q931 Specs I 
think there should be space for max. 128 octets (bytes/characters)...
Can someone point me to the place in the sources where I can check 
and adopt this?
I have tested this on an asterisk 11.3 and on an asterisk 
1.6.2.24 both show the same limit of 35 characters...


regards,
yves







--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] libss7 2.0.0 Now Available

2014-06-16 Thread Asterisk Development Team 
The Asterisk Development Team has announced the release of libss7 2.0.0.
This release is available for immediate download at
http://downloads.asterisk.org/pub/telephony/libss7

The release of libss7 2.0.0 resolves several issues reported by the
community and would not have been possible without your participation.

Please note that this version of libss7 has been released in anticipation of
what will be Asterisk 13 (currently trunk). It will not work with the existing
released versions of Asterisk.

Thank you!

The following are the issues resolved in this release:

* --- Major update to the library that is not backward compatible.
  Special thanks to Kaloyan Kovachev for his support and persistence
  in getting the patch updated and ready for release.
  (Closes issue SS7-27.  Reported by: adomjan)

For a full list of changes and descriptions of the chagnes in this
release, please see the ChangeLog:

http://downloads.asterisk.org/pub/telephony/libss7/ChangeLog-2.0.0

Thank you for your continued support of Asterisk!


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] libpri 1.4.15 Now Available

2014-06-16 Thread Asterisk Development Team 
The Asterisk Development Team has announced the release of libpri 1.4.15.
This release is available for immediate download at
http://downloads.asterisk.org/pub/telephony/libpri

The release of libpri 1.4.15 resolves several issues reported by the
community and would not have been possible without your participation.

Thank you!

The following are the issues resolved in this release:

* --- Fix hole in layer2_persistence option for TE PTMP links.
  (Closes issue LIBPRI-72.  Reported by: Trey Blancher)

* --- Make TE-PTP mode respond to MDL TEI check requests.
  (PRI-165 Reported by: Denis Alberto Martinez)

* --- Add control of inband audio progress indication ie to the
  SETUP_ACKNOWLEDGE message.
  (Closes issue AST-1338.  Reported by: Tyler Stewart)

* --- Adjust T202 default value to the minimum.
  (Closes issue PRI-171.  Reported by: dcolombo)

For a full list of changes and descriptions of the chagnes in this
release, please see the ChangeLog:

http://downloads.asterisk.org/pub/telephony/libpri/ChangeLog-1.4.15

Thank you for your continued support of Asterisk!


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3548: suspended destructions of pri spans following PRI_EVENT_REMOVED

2014-06-16 Thread rmudgett 

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3548/#review12159
---



/trunk/channels/chan_dahdi.c


You should not be directly accessing the .first and .last list members 
directly.  This is why I gave you the way it should be done earlier.



/trunk/channels/sig_pri.c


guidelines.  Function curly on its own line.


- rmudgett


On June 16, 2014, 11:07 a.m., Tzafrir Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3548/
> ---
> 
> (Updated June 16, 2014, 11:07 a.m.)
> 
> 
> Review request for Asterisk Developers and rmudgett.
> 
> 
> Bugs: ASTERISK-23554
> https://issues.asterisk.org/jira/browse/ASTERISK-23554
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Issue: when a PRI span is disconnected (e.g.: following the unassignment pri 
> spans) dahdi channels of that span can be destroyed in two different pathes:
> 
> 1. DAHDI channels are destroyed in response to pri_event_removed
> 2. The span is destroyed in response to DAHDI_EVENT_REMOVED in the D-channel. 
> Before the span is destroyed, its channels need to be destroyed.
> 
> If the channel is not in a call, (1) is run from the monitor thread, holding 
> the iflock (lock of iflist: the list of channels). somewhere in the process 
> of destroying a channel that belongs to a PRI
> span, the pri's lock needs to be acquired.
> 
> (2) is called from a context of handling the PRI events and hence holds the 
> PRI lock. Destroying the channels requires getting the iflock.
> 
> Which means that if the two happen simultaneously, we have a deadlock. And 
> the two will happen simultaneously, as recent versions of DAHDI will send an 
> extra DAHDI_EVENT_REMOVED as a response to any call to the ioctl on 
> DAHDI_GET_EVENT on a removed span.
> 
> This review includes the patches pri_destroy_span_prilist.patch and 
> sigpri_handle_enodev_1.patch from the referred bug. The former solves this 
> deadlock by creating a list of spans to be removed "later" and and thus allow 
> executing (2) without holding the pri lock.
> 
> The second patch fixes error handling of libpri: if read returns -ENODEV, we 
> have no device and it should be destroyed. This, however, requires exposing 
> the above "deferred destruction" functionality to sig_pri.
> 
> 
> Diffs
> -
> 
>   /trunk/channels/sig_pri.c 416393 
>   /trunk/channels/sig_pri.h 416393 
>   /trunk/channels/chan_dahdi.c 416393 
> 
> Diff: https://reviewboard.asterisk.org/r/3548/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tzafrir Cohen
> 
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3548: suspended destructions of pri spans following PRI_EVENT_REMOVED

2014-06-16 Thread Tzafrir Cohen 

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3548/
---

(Updated June 16, 2014, 4:07 p.m.)


Review request for Asterisk Developers and rmudgett.


Changes
---

Thanks for the feedback. Fixed most (or all) issues.

I still encountered one or two cases (unreproducable) where the lock on a pri 
(span) was held for over 3 minutes and thus it appeared as if there was a 
deadlock. It eventually got released on its own.


Bugs: ASTERISK-23554
https://issues.asterisk.org/jira/browse/ASTERISK-23554


Repository: Asterisk


Description
---

Issue: when a PRI span is disconnected (e.g.: following the unassignment pri 
spans) dahdi channels of that span can be destroyed in two different pathes:

1. DAHDI channels are destroyed in response to pri_event_removed
2. The span is destroyed in response to DAHDI_EVENT_REMOVED in the D-channel. 
Before the span is destroyed, its channels need to be destroyed.

If the channel is not in a call, (1) is run from the monitor thread, holding 
the iflock (lock of iflist: the list of channels). somewhere in the process of 
destroying a channel that belongs to a PRI
span, the pri's lock needs to be acquired.

(2) is called from a context of handling the PRI events and hence holds the PRI 
lock. Destroying the channels requires getting the iflock.

Which means that if the two happen simultaneously, we have a deadlock. And the 
two will happen simultaneously, as recent versions of DAHDI will send an extra 
DAHDI_EVENT_REMOVED as a response to any call to the ioctl on DAHDI_GET_EVENT 
on a removed span.

This review includes the patches pri_destroy_span_prilist.patch and 
sigpri_handle_enodev_1.patch from the referred bug. The former solves this 
deadlock by creating a list of spans to be removed "later" and and thus allow 
executing (2) without holding the pri lock.

The second patch fixes error handling of libpri: if read returns -ENODEV, we 
have no device and it should be destroyed. This, however, requires exposing the 
above "deferred destruction" functionality to sig_pri.


Diffs (updated)
-

  /trunk/channels/sig_pri.c 416393 
  /trunk/channels/sig_pri.h 416393 
  /trunk/channels/chan_dahdi.c 416393 

Diff: https://reviewboard.asterisk.org/r/3548/diff/


Testing
---


Thanks,

Tzafrir Cohen

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3548: suspended destructions of pri spans following PRI_EVENT_REMOVED

2014-06-16 Thread Tzafrir Cohen 


> On May 22, 2014, 7:49 p.m., opticron wrote:
> > /trunk/channels/chan_dahdi.c, lines 1173-1179
> > 
> >
> > Does this not leak everything inside sig_pri_span if this allocation 
> > fails?

I don't see how. The destruction of the pri won't happen. But that's not a leak.

Should it be made an int function that returns an error in case of failed 
allocation? What can be done in that case?


- Tzafrir


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3548/#review11962
---


On May 19, 2014, 2:32 p.m., Tzafrir Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3548/
> ---
> 
> (Updated May 19, 2014, 2:32 p.m.)
> 
> 
> Review request for Asterisk Developers and rmudgett.
> 
> 
> Bugs: ASTERISK-23554
> https://issues.asterisk.org/jira/browse/ASTERISK-23554
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Issue: when a PRI span is disconnected (e.g.: following the unassignment pri 
> spans) dahdi channels of that span can be destroyed in two different pathes:
> 
> 1. DAHDI channels are destroyed in response to pri_event_removed
> 2. The span is destroyed in response to DAHDI_EVENT_REMOVED in the D-channel. 
> Before the span is destroyed, its channels need to be destroyed.
> 
> If the channel is not in a call, (1) is run from the monitor thread, holding 
> the iflock (lock of iflist: the list of channels). somewhere in the process 
> of destroying a channel that belongs to a PRI
> span, the pri's lock needs to be acquired.
> 
> (2) is called from a context of handling the PRI events and hence holds the 
> PRI lock. Destroying the channels requires getting the iflock.
> 
> Which means that if the two happen simultaneously, we have a deadlock. And 
> the two will happen simultaneously, as recent versions of DAHDI will send an 
> extra DAHDI_EVENT_REMOVED as a response to any call to the ioctl on 
> DAHDI_GET_EVENT on a removed span.
> 
> This review includes the patches pri_destroy_span_prilist.patch and 
> sigpri_handle_enodev_1.patch from the referred bug. The former solves this 
> deadlock by creating a list of spans to be removed "later" and and thus allow 
> executing (2) without holding the pri lock.
> 
> The second patch fixes error handling of libpri: if read returns -ENODEV, we 
> have no device and it should be destroyed. This, however, requires exposing 
> the above "deferred destruction" functionality to sig_pri.
> 
> 
> Diffs
> -
> 
>   /trunk/channels/sig_pri.c 414151 
>   /trunk/channels/sig_pri.h 414151 
>   /trunk/channels/chan_dahdi.c 414151 
> 
> Diff: https://reviewboard.asterisk.org/r/3548/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tzafrir Cohen
> 
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] ISDN Userfield UUI has a length constraint?

2014-06-16 Thread Yves A. 
seems, I found the right place by myself... no wonder I could not find 
it in asterisk sources
the constraint is located in the sources of libpri I will change 
that, recompile and post feedback here...


thanks anyways,
yves

Am 16.06.2014 14:57, schrieb Yves A.:

Hi,

I am using the Q931 / ISDN USER-USER-INFO field for transferring data 
between the caller and the called party.
This works fine as long as the information does not exceed 35 
characters...
Unfortunately sometimes I need more space and due to the Q931 Specs I 
think there should be space for max. 128 octets (bytes/characters)...
Can someone point me to the place in the sources where I can check and 
adopt this?
I have tested this on an asterisk 11.3 and on an asterisk 1.6.2.24 
both show the same limit of 35 characters...


regards,
yves




--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] ISDN Userfield UUI has a length constraint?

2014-06-16 Thread Yves A. 

Hi,

I am using the Q931 / ISDN USER-USER-INFO field for transferring data 
between the caller and the called party.

This works fine as long as the information does not exceed 35 characters...
Unfortunately sometimes I need more space and due to the Q931 Specs I 
think there should be space for max. 128 octets (bytes/characters)...
Can someone point me to the place in the sources where I can check and 
adopt this?
I have tested this on an asterisk 11.3 and on an asterisk 1.6.2.24 
both show the same limit of 35 characters...


regards,
yves

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3559: sqlite3: Add ability to automatically retry query to busy database

2014-06-16 Thread Igor Goncharovsky 

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3559/
---

(Updated June 16, 2014, 3:52 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 416336


Bugs: ASTERISK-23766
https://issues.asterisk.org/jira/browse/ASTERISK-23766


Repository: Asterisk


Description
---

We have faced situation when using CDR and CEL by sqlite3 modules. With system 
having high load (~100 concurrent calls created by sipp) we found many cdr and 
cel records missed. There is special finction in sqlite3, that make able to fix 
this situation - sqlite3_wait_timeout, that also can replace awful code 
cdr_sqlite3 ad cel_sqlite3 modules. Also this function can be used for aastdb 
and res_config_sqlite3 to avoid missed writes to sqlite db.


Diffs
-

  /trunk/res/res_config_sqlite3.c 414674 
  /trunk/main/db.c 414674 
  /trunk/cel/cel_sqlite3_custom.c 414674 
  /trunk/cdr/cdr_sqlite3_custom.c 414674 

Diff: https://reviewboard.asterisk.org/r/3559/diff/


Testing
---

Adding sqlite3_wait_timeout already used as patch in AskoziaPBX and show good 
result.


Thanks,

Igor Goncharovsky

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev