Re: [asterisk-dev] Suspected chan_sip regression bug, when re-invite occurs from IPv4 to IPv6 (IPv6 is da-shit! giving us the da-shit!)

[Nir Simionovich]

Issue reported as ASTERISK-27545.

On Thu, Jan 4, 2018 at 8:36 AM Nir Simionovich 
wrote:

> Hi All,
>
>   We've recently encountered an interesting bug with Asterisk 13 (the
> version we are testing with), but I believe
> as this is a fairly crazy (although reasonable) test scenario - the issue
> may still be there.
>
>   The scenario is the following:
>
> UAC A  IPv4 + SIP + RTP > Asterisk --- IPv4 + SIP + RTP ---> UA B
>
>   When the following happens, we all know that this is working correctly,
> no problem there. However, during the
> call, the network condition changes, namely in our case: Transit from UAC
> A to Asterisk changes from IPv4 to
> IPv6, thus the following happens:
>
> UAC A  IPv6 + SIP + RTP > Asterisk --- IPv4 + SIP + RTP ---> UA B
>
>   The SDP response in the 200 OK coming back from Asterisk is malformed,
> and contains IPv4 addresses in the
> SDP, although it shouldn't. For example (pay attention to the bolded
> section):
>
> INVITE sip:4015@[2a03:b0c0:1:d0::176b:1001]:5090 SIP/2.0
> Via: SIP/2.0/UDP
> [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;rport;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1
>
> Max-Forwards: 70
> From: 
> sip:4...@xx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
>
> To: sip:6...@xx.dev.greenfieldtech.net;tag=as4b993656
> Contact: 
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 INVITE
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
> REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800;refresher=uas
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 584
>
> v=0
> o=- 3723897380 3723897382 IN IP4 100.101.10.126
> s=pjmedia
> b=AS:117
> t=0 0
> a=X-nat:0
> m=audio 4002 RTP/AVP 98 97 99 104 3 0 8 9 120 96
> c=IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> b=TIAS:96000
> a=rtcp:4003 IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> a=sendrecv
> a=rtpmap:98 speex/16000
> a=rtpmap:97 speex/8000
> a=rtpmap:99 speex/32000
> a=rtpmap:104 iLBC/8000
> a=fmtp:104 mode=30
> a=rtpmap:3 GSM/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:9 G722/8000
> a=rtpmap:120 opus/48000/2
> a=fmtp:120 useinbandfec=1
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
>
> INVITE sip:4015@[2a03:b0c0:1:d0::176b:1001]:5090 SIP/2.0
> Via: SIP/2.0/UDP
> [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;rport;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1
>
> Max-Forwards: 70
> From: 
> sip:4...@xx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
>
> To: sip:6...@xx.dev.greenfieldtech.net;tag=as4b993656
> Contact: 
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 INVITE
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
> REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800;refresher=uas
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 584
>
> v=0
> o=- 3723897380 3723897382 IN IP4 100.101.10.126
> s=pjmedia
> b=AS:117
> t=0 0
> a=X-nat:0
> m=audio 4002 RTP/AVP 98 97 99 104 3 0 8 9 120 96
> c=IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> b=TIAS:96000
> a=rtcp:4003 IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> a=sendrecv
> a=rtpmap:98 speex/16000
> a=rtpmap:97 speex/8000
> a=rtpmap:99 speex/32000
> a=rtpmap:104 iLBC/8000
> a=fmtp:104 mode=30
> a=rtpmap:3 GSM/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:9 G722/8000
> a=rtpmap:120 opus/48000/2
> a=fmtp:120 useinbandfec=1
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
>
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP
> [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1;received=2001:470:1f06:404:8562:7dba:63c9:3986;rport=5090
>
> From: 
> sip:4...@xx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
>
> To: sip:6...@xx.dev.greenfieldtech.net;tag=as4b993656
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 INVITE
> Server: Asterisk PBX 14.7.0-rc2
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: 
> Content-Length: 0
>
>
>
> *SIP/2.0 200 OK Via: SIP/2.0/UDP
> [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1;received=2001:470:1f06:404:8562:7dba:63c9:3986;rport=5090
> From: sip:4015@*xx
> *.dev.greenfieldtech.net
> ;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq To:
> sip:600@*xx
>
>
>
>
>
>
> *.dev.greenfieldtech.net ;tag=as4b993656
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE CSeq: 18030 INVITE Server:
> Asterisk PBX 14.7.0-rc2 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
> SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE 

Re: [asterisk-dev] Asterisk-11 DTMF bug ?

[Mark Murawski]

On 4/6/17 4:23 PM, Matt Fredrickson wrote:


Hey Mark,

First off, thanks for reaching out to the Asterisk community to talk
about the trouble you're having :-)

This actually is a development related mailing list - so primarily for
development of Asterisk C source code level discussions, project
policy related discussions, and sometimes protocol development related
discussions.

Your question appears to be configuration or at the very least debug
related, rather than development related.  I would try referring it to
the asterisk-users mailing list or the community.asterisk.org forums
instead.

I think you probably should add more data about your Asterisk
configuration in this case, as well as your expectations as to what
should be working and what is not working, as that is not clear to me
from your description.  Are you not seeing DTMF bridged between the
two parties in the call, or is some other DTMF triggered behavior you
expect Asterisk to be demonstrating not occurring?  These are
questions I would hope to be answered when posting a follow up on one
of the other lists.

Hope that helps, and best wishes to you in resolving your problem! :-)



Hi Matt,

As a long time community member, I do understand the split of -users and 
-dev.  This is an internal implementation question/discussion and I 
believe this is more suited to the -dev list.


I'm in the process of collecting more test cases, so far I've also 
reproduced the issue with a soft phone.  So it does appear that it's not 
dependent on the endpoint user agent to exhibit this problem.


The purpose of this post was to put out feelers to see if this was 
possibly a known issue with handling DTMF with a B2BUA scenario. While 
it may wind up being a configuration issue to fix this, the expectation 
is that with the current settings, DTMF should 'just work'.  The 
endpoint is clearly sending RFC2833, and asterisk is not interpreting it 
in the B2BUA flow.


New Details: If I switch the endpoint to SIP INFO, then asterisk does 
interpret the DTMF.  To me, this signals that this is probably a bug.  
Given all else being equal that the asterisk config has not changed, and 
switching from 2833 to info, fixes the issue.


I'll be drawing out some diagrams and describing some test cases within 
a day or two.



--
_
-- 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] Asterisk-11 DTMF bug ?

[Matt Fredrickson]

On Tue, Apr 4, 2017 at 4:23 PM, Mark Murawski
 wrote:
> So... more information.
>
> directmedia=no
> directrtpsetup=no
>
> In this situation below, asterisk is the B2BUA.  Call comes in from Polycom,
> then gets routed out to ITSP via Dial()
>
> When the polycom directly calls into dialplan that handles media, asterisk
> *does* process the DTMF
> ie: Polycom calls into Read()
>
> [2017-04-04 17:21:41.557] [C-175d]  Got  RTP RFC2833 from
> 10.0.90.6:8110 (type 101, seq 016608, ts 3618850425, len 04, mark 1,
> event 0003, end 0, duration 00160)
>
>
>
>
> On 04/04/2017 04:52 PM, Mark Murawski wrote:
>>
>> Er, small correction.  Asterisk clearly shows RTP *flowing*, but not
>> receiving DTMF from 10.0.90.6
>>
>>
>>
>>
>> On 04/04/17 16:37, Mark Murawski wrote:
>>>
>>> Hey,
>>>
>>> So, I'm seeing an issue where a Polycom IP-550 with 4.1.1 firmware is
>>> sending RFC2833 DTMF packets as shown in the capture attached. I can
>>> send pcaps as necessary, if needed.
>>>
>>> 10.0.90.6 is the Polycom 10.0.90.1 is Asterisk.
>>>
>>> So of course you do:

 rtp set debug 10.0.90.6
>>>
>>>
>>> And then get the below, while the polycom is sending digits. The packet
>>> capture clearly shows DTMF going to 10.0.90.1, but Asterisk is not
>>> picking them up.
>>>
>>> [2017-04-04 14:14:18.830] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:18.830] [C-1424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:18.850] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:18.850] [C-1424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:18.870] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:18.870] [C-1424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:18.890] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:18.890] [C-1424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> ...
>>> [2017-04-04 14:14:22.210] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:22.210] [C-1424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:22.230] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:22.230] [C-1424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:22.250] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:22.250] [C-1424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:22.270] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:22.270] [C-1424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>>
>>>
>>> I am running 11.20 on this particular box, for some specific reasons.
>>> I'm currently working out some other issues with the newer/latest 11's,
>>> so I'm on this for now.
>>>
>>> Before I start digging into the code, are there any known issues with
>>> DTMF/RFC2833 in this version?  Any workarounds I can implement?

Hey Mark,

First off, thanks for reaching out to the Asterisk community to talk
about the trouble you're having :-)

This actually is a development related mailing list - so primarily for
development of Asterisk C source code level discussions, project
policy related discussions, and sometimes protocol development related
discussions.

Your question appears to be configuration or at the very least debug
related, rather than development related.  I would try referring it to
the asterisk-users mailing list or the community.asterisk.org forums
instead.

I think you probably should add more data about your Asterisk
configuration in this case, as well as your expectations as to what
should be working and what is not working, as that is not clear to me
from your description.  Are you not seeing DTMF bridged between the
two parties in the call, or is some other DTMF triggered behavior you
expect Asterisk to be demonstrating not occurring?  These are
questions I would hope to be answered when posting a follow up on one
of the other lists.

Hope that helps, and best wishes to you in resolving your problem! :-)

-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

-- 
_
-- 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] Asterisk-11 DTMF bug ?

[Mark Murawski]

So... more information.

directmedia=no
directrtpsetup=no

In this situation below, asterisk is the B2BUA.  Call comes in from 
Polycom, then gets routed out to ITSP via Dial()


When the polycom directly calls into dialplan that handles media, 
asterisk *does* process the DTMF

ie: Polycom calls into Read()

[2017-04-04 17:21:41.557] [C-175d]  Got  RTP RFC2833 from  
10.0.90.6:8110 (type 101, seq 016608, ts 3618850425, len 04, mark 1, 
event 0003, end 0, duration 00160)




On 04/04/2017 04:52 PM, Mark Murawski wrote:
Er, small correction.  Asterisk clearly shows RTP *flowing*, but not 
receiving DTMF from 10.0.90.6





On 04/04/17 16:37, Mark Murawski wrote:

Hey,

So, I'm seeing an issue where a Polycom IP-550 with 4.1.1 firmware is
sending RFC2833 DTMF packets as shown in the capture attached. I can
send pcaps as necessary, if needed.

10.0.90.6 is the Polycom 10.0.90.1 is Asterisk.

So of course you do:

rtp set debug 10.0.90.6


And then get the below, while the polycom is sending digits. The packet
capture clearly shows DTMF going to 10.0.90.1, but Asterisk is not
picking them up.

[2017-04-04 14:14:18.830] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.830] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.850] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.850] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.870] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.870] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.890] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.890] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
...
[2017-04-04 14:14:22.210] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.210] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.230] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.230] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.250] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.250] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.270] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.270] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)


I am running 11.20 on this particular box, for some specific reasons.
I'm currently working out some other issues with the newer/latest 11's,
so I'm on this for now.

Before I start digging into the code, are there any known issues with
DTMF/RFC2833 in this version?  Any workarounds I can implement?









--
_
-- 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] Asterisk-11 DTMF bug ?

[Mark Murawski]

Er, small correction.  Asterisk clearly shows RTP *flowing*, but not 
receiving DTMF from 10.0.90.6





On 04/04/17 16:37, Mark Murawski wrote:

Hey,

So, I'm seeing an issue where a Polycom IP-550 with 4.1.1 firmware is
sending RFC2833 DTMF packets as shown in the capture attached.  I can
send pcaps as necessary, if needed.

10.0.90.6 is the Polycom 10.0.90.1 is Asterisk.

So of course you do:

rtp set debug 10.0.90.6


And then get the below, while the polycom is sending digits.  The packet
capture clearly shows DTMF going to 10.0.90.1, but Asterisk is not
picking them up.

[2017-04-04 14:14:18.830] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.830] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.850] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.850] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.870] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.870] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.890] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.890] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
...
[2017-04-04 14:14:22.210] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.210] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.230] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.230] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.250] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.250] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.270] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.270] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)


I am running 11.20 on this particular box, for some specific reasons.
I'm currently working out some other issues with the newer/latest 11's,
so I'm on this for now.

Before I start digging into the code, are there any known issues with
DTMF/RFC2833 in this version?  Any workarounds I can implement?






--
_
-- 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] Asterisk-11 DTMF bug ?

[Mark Murawski]

Hey,

So, I'm seeing an issue where a Polycom IP-550 with 4.1.1 firmware is 
sending RFC2833 DTMF packets as shown in the capture attached.  I can 
send pcaps as necessary, if needed.


10.0.90.6 is the Polycom 10.0.90.1 is Asterisk.

So of course you do:
> rtp set debug 10.0.90.6

And then get the below, while the polycom is sending digits.  The packet 
capture clearly shows DTMF going to 10.0.90.1, but Asterisk is not 
picking them up.


[2017-04-04 14:14:18.830] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:18.830] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.850] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:18.850] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.870] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:18.870] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.890] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:18.890] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)

...
[2017-04-04 14:14:22.210] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:22.210] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.230] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:22.230] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.250] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:22.250] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.270] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:22.270] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)



I am running 11.20 on this particular box, for some specific reasons. 
I'm currently working out some other issues with the newer/latest 11's, 
so I'm on this for now.


Before I start digging into the code, are there any known issues with 
DTMF/RFC2833 in this version?  Any workarounds I can implement?


-- 
_
-- 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] Asterisk ARI Recordings Bug?

[Malcolm Davenport]

Howdy,

On Wed, May 18, 2016 at 12:20 PM, Michael Petruzzello <
michael.petruzze...@civi.com> wrote:

>
> Joshua Colp wrote:
> > Michael Petruzzello wrote:
> > >
> > > Joshua Colp wrote:
> > >  > What precise version of Asterisk is this? Have you seen it outside
> of
> > >  > ARI? I'd post this information in an issue[1] with any other
> information
> > >  > you have.
> > >  >
> > >  > [1] https://issues.asterisk.org/jira
> > >
> > > The version of Asterisk is 13.1-cert4. I don't interact with Asterisk
> > > outside of the ARI, so I don't know if it occurs there as well.
> >
> > Asterisk Certified 13.1 is quite old now, so the underlying issue may
> > have been fixed by now. If you are a commercial customer I'd advise
> > contacting Digium Technical Support[1], otherwise we'd only accept an
> > issue on the public issue tracker against 13.9. I do remember issues
> > with tests and recordings not being correct, but that was many months
> ago.
> >
> > Cheers,
> >
> > [1] https://www.digium.com/company/contact-digium
>
> Do you recommend the Asterisk 13 release branch over the Asterisk 13
> certified release branch? I have been using the certified release because
> it is advertised as more tested and stable.
>
> The service that I'm using Asterisk for is B2B and not a pbx, so the
> branch I am on has to be extremely reliable.
>

We don't typically provide guidance one way or the other.  You need to make
the decisions that are best for you.

The -cert branches are longer lived, but only get fixes specific to
Digium's commercial customers - we don't roll new releases of it
otherwise.  This makes it slightly less risky, if you assume that any
change introduces risk.

The mainline branches are shorter lived, get all of the fixes and are
rolled at semi-regular intervals.  This makes it slightly more risky, if
you assume that any change introduces risk.

Josh' suggestion for you to have a crack at something newer than 13.1-cert,
for your specific issue, is a good one, as there's been a great deal of
change in ARI-land since 13.1-cert.

Cheers


>
> Thank you for your assistance.
>
>
> *Michael J. Petruzzello*
> Software Engineer
> P.O. Box 4689
> Greenwich, CT 06831
> 203-618-1811 ext.289 (office)
> www.civi.com
>
> --
> _
> -- 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
>



-- 
--
Malcolm Davenport
Digium, Inc. | Senior Product Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Tel/Fax: +1 256 428 6252
malco...@digium.com
-- 
_
-- 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] Asterisk ARI Recordings Bug?

[Michael Petruzzello]

Joshua Colp wrote:
> Michael Petruzzello wrote:
> >
> > Joshua Colp wrote:
> >  > What precise version of Asterisk is this? Have you seen it outside of
> >  > ARI? I'd post this information in an issue[1] with any other
information
> >  > you have.
> >  >
> >  > [1] https://issues.asterisk.org/jira
> >
> > The version of Asterisk is 13.1-cert4. I don't interact with Asterisk
> > outside of the ARI, so I don't know if it occurs there as well.
>
> Asterisk Certified 13.1 is quite old now, so the underlying issue may
> have been fixed by now. If you are a commercial customer I'd advise
> contacting Digium Technical Support[1], otherwise we'd only accept an
> issue on the public issue tracker against 13.9. I do remember issues
> with tests and recordings not being correct, but that was many months ago.
>
> Cheers,
>
> [1] https://www.digium.com/company/contact-digium

Do you recommend the Asterisk 13 release branch over the Asterisk 13
certified release branch? I have been using the certified release because
it is advertised as more tested and stable.

The service that I'm using Asterisk for is B2B and not a pbx, so the branch
I am on has to be extremely reliable.

Thank you for your assistance.


*Michael J. Petruzzello*
Software Engineer
P.O. Box 4689
Greenwich, CT 06831
203-618-1811 ext.289 (office)
www.civi.com
-- 
_
-- 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] Asterisk ARI Recordings Bug?

[Joshua Colp]

Michael Petruzzello wrote:


Joshua Colp wrote:
 > What precise version of Asterisk is this? Have you seen it outside of
 > ARI? I'd post this information in an issue[1] with any other information
 > you have.
 >
 > [1] https://issues.asterisk.org/jira

The version of Asterisk is 13.1-cert4. I don't interact with Asterisk
outside of the ARI, so I don't know if it occurs there as well.


Asterisk Certified 13.1 is quite old now, so the underlying issue may 
have been fixed by now. If you are a commercial customer I'd advise 
contacting Digium Technical Support[1], otherwise we'd only accept an 
issue on the public issue tracker against 13.9. I do remember issues 
with tests and recordings not being correct, but that was many months ago.


Cheers,

[1] https://www.digium.com/company/contact-digium

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org


--
_
-- 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] Asterisk ARI Recordings Bug?

[Michael Petruzzello]

Joshua Colp wrote:
> What precise version of Asterisk is this? Have you seen it outside of
> ARI? I'd post this information in an issue[1] with any other information
> you have.
>
> [1] https://issues.asterisk.org/jira

The version of Asterisk is 13.1-cert4. I don't interact with Asterisk
outside of the ARI, so I don't know if it occurs there as well.


*Michael J. Petruzzello*
Software Engineer
P.O. Box 4689
Greenwich, CT 06831
203-618-1811 ext.289 (office)
www.civi.com
-- 
_
-- 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] Asterisk ARI Recordings Bug?

[Joshua Colp]

Michael Petruzzello wrote:

Joshua Colp wrote:
 >Whether it's ARI or not the same things are used underneath. What file
 >format and what says they are unplayable

The file format is wav. Groove Music and Audacity (regular import) says
they are unplayable.

Looking at the file headers, the unplayable recordings are missing the
chunkSize and the subchunk2Size:

52 49 46 46 00 00 00 00 57 41 56 45 66 6d 74 20 10 00 00 00 01 00 40 1f
00 00 80 3e 00 00 02 00 10 00 64 61 74 61 00 00 00 00 94 fd d4 fd

It looks like Asterisk writes the wav file with an invalid header
because it is currently writing out to the file, but then it fails to
rewrite with the correct length data when the recording finishes.


What precise version of Asterisk is this? Have you seen it outside of 
ARI? I'd post this information in an issue[1] with any other information 
you have.


[1] https://issues.asterisk.org/jira

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org


--
_
-- 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] Asterisk ARI Recordings Bug?

[Michael Petruzzello]

Joshua Colp wrote:
>Whether it's ARI or not the same things are used underneath. What file
>format and what says they are unplayable

The file format is wav. Groove Music and Audacity (regular import) says
they are unplayable.

Looking at the file headers, the unplayable recordings are missing the
chunkSize and the subchunk2Size:

52 49 46 46 00 00 00 00 57 41 56 45 66 6d 74 20 10 00 00 00 01 00 40 1f 00
00 80 3e 00 00 02 00 10 00 64 61 74 61 00 00 00 00 94 fd d4 fd

It looks like Asterisk writes the wav file with an invalid header because
it is currently writing out to the file, but then it fails to rewrite with
the correct length data when the recording finishes.


*Michael J. Petruzzello*
Software Engineer
P.O. Box 4689
Greenwich, CT 06831
203-618-1811 ext.289 (office)
www.civi.com
-- 
_
-- 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] Asterisk ARI Recordings Bug?

[Joshua Colp]

Michael Petruzzello wrote:

Hello,

I am creating recordings through Asterisk's rest interface, and that
generally works very well. In some occasions, recordings that are longer
than 10-15 minutes in duration are unplayable. I end up having to import
the file as raw data into Audacity, and then however I export the file
it plays just fine.

I've looked for more information on this issue, but I generally just
find issues about trying to play audio in Asterisk that end up being
encoded wrong.


Whether it's ARI or not the same things are used underneath. What file 
format and what says they are unplayable?


--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_
-- 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] Asterisk ARI Recordings Bug?

[Michael Petruzzello]

Hello,

I am creating recordings through Asterisk's rest interface, and that
generally works very well. In some occasions, recordings that are longer
than 10-15 minutes in duration are unplayable. I end up having to import
the file as raw data into Audacity, and then however I export the file it
plays just fine.

I've looked for more information on this issue, but I generally just find
issues about trying to play audio in Asterisk that end up being encoded
wrong.



*Michael J. Petruzzello*
Software Engineer
P.O. Box 4689
Greenwich, CT 06831
203-618-1811 ext.289 (office)
www.civi.com
-- 
_
-- 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] BOUNTY $1000: ARI Bug Crashes Asterisk

[Sidney VanNess]

Pardon the re-post. Bumping bounty to $1000.  If we don't hear from anyone
in the next few days, we likely will put someone on this ourselves, or find
a workaround, so please contact us prior to starting if interested.

We would like to offer a bounty to fix a bug(s) in ARI that is causing
Asterisk to crash. The issue arises in the latest stable LTS release when
you do the following:

*Description/How To Reproduce*
$ wscat -c
'ws://localhost:8088/ari/events?api_key=:==1
#

Run 5 or 10 of these at once with appname different for each one with all
of them subscribing to all events.

Place a call which will emit stasisStart for one of the apps (maybe a few
times).

Asterisk should terminate at this point.

*This was done using local channels

json_mem_free in json.c seems to have the issue.  If you don't free the
memory, then it does not terminate.

Of note, the issue seems somewhat similar in nature to the following bug
report:

*issues.asterisk.org/jira/browse/ASTERISK-25775*

Therefore, we expect the fix to our issue also would result in the
resolution of this seemingly related bug report.

Please refer all technical questions to the listed technical contact; refer
all business questions to the listed business contact.

*Technical Contact*
Brian Smith
Skype: wormling
Email:  *brian.sm...@oncallcentral.com*

*Business Contact*
Sidney VanNess, Ph.D.
President & CEO, Acumantra Solutions, Inc.
Skype: sidneyvanness
Email:  *sid...@oncallcentral.com*

Terms
Subject to review & verification by listed technical contact. Fix to be
offered back to Asterisk as an open source patch. If you would like to run
this through a freelancing site such as Upwork, that also would be fine.

-- 
Sidney H. VanNess, Ph.D.
President & CEO
On Call Central
p | 859-317-7957
e | sid...@oncallcentral.com
-- 
_
-- 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] BOUNTY $500: ARI Bug Crashes Asterisk

[Sidney VanNess]

BOUNTY $500: ARI Bug Crashes Asterisk

We would like to offer a bounty to fix a bug(s) in ARI that is causing Asterisk 
to crash.The issue arises in the latest stable LTS release when you do the 
following:

Description/How To Reproduce
$ wscat -c 
'ws://localhost:8088/ari/events?api_key=:==1
 #

Run 5 or 10 of these at once with appname different for each one with all of 
them subscribing to all events.

Place a call which will emit stasisStart for one of the apps (maybe a few 
times).

Asterisk should terminate at this point.

*This was done using local channels

json_mem_free in json.c seems to have the issue.If you don't free the memory, 
then it does not terminate.

Of note, the issue seems somewhat similar in nature to the following bug report:
issues.asterisk.org/jira/browse/ASTERISK-25775

Therefore, we expect the fix to our issue also would result in the resolution 
of this seemingly related bug report.

Please refer all technical questions to the listed technical contact; refer all 
business questions to the listed business contact.

Technical Contact
Brian Smith
Skype: wormling
Email:brian.sm...@oncallcentral.com

Business Contact
Sidney VanNess, Ph.D.
President, Acumantra Solutions, Inc.
Skype: sidneyvanness
Email:sid...@oncallcentral.com

Terms
Subject to review by listed technical contact. Fix to be offered 
back to Asterisk as an open source patch. If you would like to run this through 
a freelancing site such as Upwork, that also would be fine.

--
Sidney H. VanNess, Ph.D.
President
On Call Central
p |859-317-7957
e |sid...@oncallcentral.com

-- 
_
-- 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] 4285: Bug fixes for ARI Originate/Continue with label support (Continuation of /r/4101)

[Mark Michelson]

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

(Updated Jan. 7, 2015, 12:53 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 430337


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


Repository: Asterisk


Description
---

See /r/4101 for the initial review uploaded by Nir Simionivich to understand 
the need for the ability to originate/continue to a labeled dialplan priority.

When writing the tests in /r/4284 for continuation/origination, I ran into some 
problems, and so I have updated the original patch to fix these issues. Here 
are the modifications to the original patch:

* In continuation code, we get a channel snapshot from the stasis_app_control 
instead of getting an actual channel instance. This is because 
pbx_findlabel_extension doesn't actually use the channel for anything, so the 
channel isn't necessary.
* In both continuation and origination code, do not pass the input context to 
pbx_findlabel_extension. If no context is specified, this causes a crash. 
Instead, determine the intended context beforehand and pass that context into 
pbx_findlabel_extension.
* This is not a fault of the previous patch, but there were code paths that 
resulted in some unexpected behavior in continuation. Since continuation states 
that context, extension, priority, and label are all optional, but didn't 
really do anything to make sense of what should happen when one or more are 
omitted, the code has been updated to make sure that a sane default is used 
when one or more of these are omitted.
* I have updated the apiVersion in rest-api/resources.json to 1.7.0 since 
this change introduces backwards-compatible new functionality. QUESTION: Is 
this version bump required in other .json files as well?
* I have updated CHANGES to indicate the new functionality


Diffs
-

  /branches/13/rest-api/resources.json 430178 
  /branches/13/rest-api/api-docs/channels.json 430178 
  /branches/13/res/res_ari_channels.c 430178 
  /branches/13/res/ari/resource_channels.c 430178 
  /branches/13/res/ari/resource_channels.h 430178 
  /branches/13/CHANGES 430178 

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


Testing
---

See /r/4284 for tests.


Thanks,

Mark Michelson

-- 
_
-- 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] 4285: Bug fixes for ARI Originate/Continue with label support (Continuation of /r/4101)

[Joshua Colp]

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

Ship it!


Ship It!

- Joshua Colp


On Jan. 6, 2015, 10:21 p.m., Mark Michelson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4285/
 ---
 
 (Updated Jan. 6, 2015, 10:21 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24412
 https://issues.asterisk.org/jira/browse/ASTERISK-24412
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 See /r/4101 for the initial review uploaded by Nir Simionivich to understand 
 the need for the ability to originate/continue to a labeled dialplan priority.
 
 When writing the tests in /r/4284 for continuation/origination, I ran into 
 some problems, and so I have updated the original patch to fix these issues. 
 Here are the modifications to the original patch:
 
 * In continuation code, we get a channel snapshot from the stasis_app_control 
 instead of getting an actual channel instance. This is because 
 pbx_findlabel_extension doesn't actually use the channel for anything, so the 
 channel isn't necessary.
 * In both continuation and origination code, do not pass the input context to 
 pbx_findlabel_extension. If no context is specified, this causes a crash. 
 Instead, determine the intended context beforehand and pass that context into 
 pbx_findlabel_extension.
 * This is not a fault of the previous patch, but there were code paths that 
 resulted in some unexpected behavior in continuation. Since continuation 
 states that context, extension, priority, and label are all optional, but 
 didn't really do anything to make sense of what should happen when one or 
 more are omitted, the code has been updated to make sure that a sane default 
 is used when one or more of these are omitted.
 * I have updated the apiVersion in rest-api/resources.json to 1.7.0 since 
 this change introduces backwards-compatible new functionality. QUESTION: Is 
 this version bump required in other .json files as well?
 * I have updated CHANGES to indicate the new functionality
 
 
 Diffs
 -
 
   /branches/13/rest-api/resources.json 430178 
   /branches/13/rest-api/api-docs/channels.json 430178 
   /branches/13/res/res_ari_channels.c 430178 
   /branches/13/res/ari/resource_channels.c 430178 
   /branches/13/res/ari/resource_channels.h 430178 
   /branches/13/CHANGES 430178 
 
 Diff: https://reviewboard.asterisk.org/r/4285/diff/
 
 
 Testing
 ---
 
 See /r/4284 for tests.
 
 
 Thanks,
 
 Mark Michelson
 


-- 
_
-- 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] 4285: Bug fixes for ARI Originate/Continue with label support (Continuation of /r/4101)

[Mark Michelson]

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

(Updated Jan. 6, 2015, 10:21 p.m.)


Review request for Asterisk Developers.


Changes
---

Added same error message to origination as well.


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


Repository: Asterisk


Description
---

See /r/4101 for the initial review uploaded by Nir Simionivich to understand 
the need for the ability to originate/continue to a labeled dialplan priority.

When writing the tests in /r/4284 for continuation/origination, I ran into some 
problems, and so I have updated the original patch to fix these issues. Here 
are the modifications to the original patch:

* In continuation code, we get a channel snapshot from the stasis_app_control 
instead of getting an actual channel instance. This is because 
pbx_findlabel_extension doesn't actually use the channel for anything, so the 
channel isn't necessary.
* In both continuation and origination code, do not pass the input context to 
pbx_findlabel_extension. If no context is specified, this causes a crash. 
Instead, determine the intended context beforehand and pass that context into 
pbx_findlabel_extension.
* This is not a fault of the previous patch, but there were code paths that 
resulted in some unexpected behavior in continuation. Since continuation states 
that context, extension, priority, and label are all optional, but didn't 
really do anything to make sense of what should happen when one or more are 
omitted, the code has been updated to make sure that a sane default is used 
when one or more of these are omitted.
* I have updated the apiVersion in rest-api/resources.json to 1.7.0 since 
this change introduces backwards-compatible new functionality. QUESTION: Is 
this version bump required in other .json files as well?
* I have updated CHANGES to indicate the new functionality


Diffs (updated)
-

  /branches/13/rest-api/resources.json 430178 
  /branches/13/rest-api/api-docs/channels.json 430178 
  /branches/13/res/res_ari_channels.c 430178 
  /branches/13/res/ari/resource_channels.c 430178 
  /branches/13/res/ari/resource_channels.h 430178 
  /branches/13/CHANGES 430178 

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


Testing
---

See /r/4284 for tests.


Thanks,

Mark Michelson

-- 
_
-- 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] 4285: Bug fixes for ARI Originate/Continue with label support (Continuation of /r/4101)

[Mark Michelson]

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

(Updated Jan. 6, 2015, 10:20 p.m.)


Review request for Asterisk Developers.


Changes
---

Changed the error message Josh pointed out to simply point out that the entered 
priority label is invalid.


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


Repository: Asterisk


Description
---

See /r/4101 for the initial review uploaded by Nir Simionivich to understand 
the need for the ability to originate/continue to a labeled dialplan priority.

When writing the tests in /r/4284 for continuation/origination, I ran into some 
problems, and so I have updated the original patch to fix these issues. Here 
are the modifications to the original patch:

* In continuation code, we get a channel snapshot from the stasis_app_control 
instead of getting an actual channel instance. This is because 
pbx_findlabel_extension doesn't actually use the channel for anything, so the 
channel isn't necessary.
* In both continuation and origination code, do not pass the input context to 
pbx_findlabel_extension. If no context is specified, this causes a crash. 
Instead, determine the intended context beforehand and pass that context into 
pbx_findlabel_extension.
* This is not a fault of the previous patch, but there were code paths that 
resulted in some unexpected behavior in continuation. Since continuation states 
that context, extension, priority, and label are all optional, but didn't 
really do anything to make sense of what should happen when one or more are 
omitted, the code has been updated to make sure that a sane default is used 
when one or more of these are omitted.
* I have updated the apiVersion in rest-api/resources.json to 1.7.0 since 
this change introduces backwards-compatible new functionality. QUESTION: Is 
this version bump required in other .json files as well?
* I have updated CHANGES to indicate the new functionality


Diffs (updated)
-

  /branches/13/rest-api/resources.json 430178 
  /branches/13/rest-api/api-docs/channels.json 430178 
  /branches/13/res/res_ari_channels.c 430178 
  /branches/13/res/ari/resource_channels.c 430178 
  /branches/13/res/ari/resource_channels.h 430178 
  /branches/13/CHANGES 430178 

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


Testing
---

See /r/4284 for tests.


Thanks,

Mark Michelson

-- 
_
-- 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] 4285: Bug fixes for ARI Originate/Continue with label support (Continuation of /r/4101)

[Joshua Colp]

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



/branches/13/res/ari/resource_channels.c
https://reviewboard.asterisk.org/r/4285/#comment24540

I don't think this is the correct message to put here. They didn't request 
priority 0, it just so happens that what they provided yielded us to having a 
priority of 0. I could see something being confused if they saw this.


- Joshua Colp


On Dec. 19, 2014, 5:15 p.m., Mark Michelson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4285/
 ---
 
 (Updated Dec. 19, 2014, 5:15 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24412
 https://issues.asterisk.org/jira/browse/ASTERISK-24412
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 See /r/4101 for the initial review uploaded by Nir Simionivich to understand 
 the need for the ability to originate/continue to a labeled dialplan priority.
 
 When writing the tests in /r/4284 for continuation/origination, I ran into 
 some problems, and so I have updated the original patch to fix these issues. 
 Here are the modifications to the original patch:
 
 * In continuation code, we get a channel snapshot from the stasis_app_control 
 instead of getting an actual channel instance. This is because 
 pbx_findlabel_extension doesn't actually use the channel for anything, so the 
 channel isn't necessary.
 * In both continuation and origination code, do not pass the input context to 
 pbx_findlabel_extension. If no context is specified, this causes a crash. 
 Instead, determine the intended context beforehand and pass that context into 
 pbx_findlabel_extension.
 * This is not a fault of the previous patch, but there were code paths that 
 resulted in some unexpected behavior in continuation. Since continuation 
 states that context, extension, priority, and label are all optional, but 
 didn't really do anything to make sense of what should happen when one or 
 more are omitted, the code has been updated to make sure that a sane default 
 is used when one or more of these are omitted.
 * I have updated the apiVersion in rest-api/resources.json to 1.7.0 since 
 this change introduces backwards-compatible new functionality. QUESTION: Is 
 this version bump required in other .json files as well?
 * I have updated CHANGES to indicate the new functionality
 
 
 Diffs
 -
 
   /branches/13/rest-api/resources.json 429698 
   /branches/13/rest-api/api-docs/channels.json 429698 
   /branches/13/res/res_ari_channels.c 429698 
   /branches/13/res/ari/resource_channels.c 429698 
   /branches/13/res/ari/resource_channels.h 429698 
   /branches/13/CHANGES 429698 
 
 Diff: https://reviewboard.asterisk.org/r/4285/diff/
 
 
 Testing
 ---
 
 See /r/4284 for tests.
 
 
 Thanks,
 
 Mark Michelson
 


-- 
_
-- 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] [Code Review] 4285: Bug fixes for ARI Originate/Continue with label support (Continuation of /r/4101)

[Mark Michelson]

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

Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

See /r/4101 for the initial review uploaded by Nir Simionivich to understand 
the need for the ability to originate/continue to a labeled dialplan priority.

When writing the tests in /r/4284 for continuation/origination, I ran into some 
problems, and so I have updated the original patch to fix these issues. Here 
are the modifications to the original patch:

* In continuation code, we get a channel snapshot from the stasis_app_control 
instead of getting an actual channel instance. This is because 
pbx_findlabel_extension doesn't actually use the channel for anything, so the 
channel isn't necessary.
* In both continuation and origination code, do not pass the input context to 
pbx_findlabel_extension. If no context is specified, this causes a crash. 
Instead, determine the intended context beforehand and pass that context into 
pbx_findlabel_extension.
* This is not a fault of the previous patch, but there were code paths that 
resulted in some unexpected behavior in continuation. Since continuation states 
that context, extension, priority, and label are all optional, but didn't 
really do anything to make sense of what should happen when one or more are 
omitted, the code has been updated to make sure that a sane default is used 
when one or more of these are omitted.
* I have updated the apiVersion in rest-api/resources.json to 1.7.0 since 
this change introduces backwards-compatible new functionality. QUESTION: Is 
this version bump required in other .json files as well?
* I have updated CHANGES to indicate the new functionality


Diffs
-

  /branches/13/rest-api/resources.json 429698 
  /branches/13/rest-api/api-docs/channels.json 429698 
  /branches/13/res/res_ari_channels.c 429698 
  /branches/13/res/ari/resource_channels.c 429698 
  /branches/13/res/ari/resource_channels.h 429698 
  /branches/13/CHANGES 429698 

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


Testing
---

See /r/4284 for tests.


Thanks,

Mark Michelson

-- 
_
-- 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] Attn Olle: closed bug #9239 - xfersound

[Johansson Olle E]

31 jan 2008 kl. 15.43 skrev Steve Davies:

 On Jan 31, 2008 10:39 AM, Johansson Olle E [EMAIL PROTECTED] wrote:
 Late answer, found in my mail queue. Obviously did not get sent on  
 the
 airport...

 /O

 23 jan 2008 kl. 21.03 skrev Nic Bellamy:

 Hi Olle,
 you closed off the above bug yesterday, or thereabouts, with a
 comment:

 No answer from reporter, and it's doable in dialplan.

 The No answer from reporter part is easy enough to understand
 (yes, it
 had been a while), but you have commented a couple of times during  
 the
 life of the bug that it's doable in the dialplan.

 I can't for the life of me think how to do it in the dialplan, so if
 it
 can be done, please please please enlighten me.

 The basic idea is to have a notification beep play when an attended
 transfer is completed - ie.:

 1. A rings B, B answers. A wants to talk to C
 2. B rings C, C answers. C says go ahead
 3. B completes attended transfer
 4. B-C bridge gets replaced with A-C bridge - but C would like a
 beep! when this happens. Currently, unless there's a significant
 change in background noise, it's very hard for C to tell when B-C
 changes to A-C


 For  blind transfers:

 Catch the new call in the TRANSFER_CONTEXT, play a beep and
 go ahead.

 Attended transfers are harder, you're right. There's obviously no
 dialplan execution at time of transfer. I am a bit afraid of  
 duplicating
 too much code of the PBX transfer in res_features into chan_sip and
 building my own PBX in the SIP channel, so I am very hesitant for
 this type of patches...

 I guess I will have to revisit this bug. Thanks for the correction
 and the reminder.

 /O :-)


 I would personally love to see this implemented as a parameter to
 Dial(), perhaps a B(macro) parameter which works a bit like M(macro),
 except that is is executed whenever any sort of call bridge is
 completed, rather than when the call is answered. The macro would be
 called with a couple of system variables set to indicate channels
 involved, and the type of transfer taking place.

 One complication - There might be 2 call legs with either the same or
 different B() parameters specified... This would need resolving!

 This feature would allow more than just a Beep to be played, it would
 allow call-recording settings to be re-evaluated for the newly bridged
 call, MoH settings to be changed, CDR updates, and all sorts of other
 useless behaviour that keeps end-user happy :)

 Of course, ideally M() and B() behaviour would also be available to
 app_queue originated calls.

That's a cool idea which also takes it out of the SIP scope :-)
We just need to make sure that chan_sip and other channels
activate this in the same way as the new features non-module does.

/O

___
--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] bugs.digium.com notification on bug closure

[Bisker, Scott (7805)]

Is there any reason why an email isn't sent when bugs are being closed?
 I looked at my prefs, and the Email on closed was checked.   The only two 
that weren't checked were Email on Status Change and Email on Priority 
Change


-sb




CONFIDENTIALITY NOTICE: 
This e-mail, and any attachments, is for the sole use of the intended 
recipient(s) and may contain information that is confidential and 
protected from disclosure under the law. Any unauthorized review, use, 
disclosure, or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply e-mail, and delete/destroy 
all copies of the original message and attachments. 
Thank you.___
--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] bugs.digium.com notification on bug closure

[Russell Bryant]

Bisker, Scott (7805) wrote:
 Is there any reason why an email isn't sent when bugs are being closed?

I'm getting emails when bugs get closed just fine ...

-- 
Russell Bryant
Software Engineer
Digium, Inc.

___
--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] Fixing Asterisk DNS - bug 9152, asynchronous DNS, etc

[Olle E Johansson]

21 jun 2007 kl. 22.42 skrev Russell Bryant:

 Olle E Johansson wrote:
 21 jun 2007 kl. 18.08 skrev Russell Bryant:
 We already have an asynchronous DNS handler.  It's just that most
 of the
 code hasn't been converted to use it.  It is open for anyone to
 jump on
 and as I said before, it's not terribly difficult to do, but it will
 take some time.

 Do we? Where's that code?

 implementation: main/dnsmgr.c
 example usage: channels/chan_iax2.c

Hmm, last time I checked this wasn't really what the rest of the  
world calls asynch DNS,
but things may have changed and I will check again. Kevin also used  
to have some doubt
whether dnsmgr was the right way to go, so I put implementation of  
that on hold for
chan_sip, but if it's now the proper way, I'll look into it again and  
see if we can enhance
it so it can help us improve DNS support, especially in the area of  
SRV records in SIP.

If someone else wants to take a look, that would be really, really  
helpful.

If dnsmgr is not asynch DNS, I suggest that someone takes a look into  
the C-ares library.
It has a license that Kevin/Mark has approved of and will help us to  
proper asynch
DNS. It's used by curl, so in some installations it's already used by  
asterisk in app_curl.

/O

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Fixing Asterisk DNS - bug 9152, asynchronous DNS, etc

[Klaus Darilion]

Olle E Johansson wrote:
 If dnsmgr is not asynch DNS, I suggest that someone takes a look into  
 the C-ares library.
 It has a license that Kevin/Mark has approved of and will help us to  
 proper asynch
 DNS. It's used by curl, so in some installations it's already used by  
 asterisk in app_curl.

FYI: There is also an extended version of ares included in the 
resiprocate stack.


klaus

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Fixing Asterisk DNS - bug 9152, asynchronous DNS, etc

[Olle E Johansson]

21 jun 2007 kl. 18.08 skrev Russell Bryant:

 Klaus Darilion wrote:
 (open)ser also has similar problems to due lack of asynch DNS -  
 but at
 least they allow to configure DNS timeouts. Thus, a workaround is
 setting low timeout values. I do not know if Asterisk supports this -
 but surely will be easier to implement than asynch DNS.

 We already have an asynchronous DNS handler.  It's just that most  
 of the
 code hasn't been converted to use it.  It is open for anyone to  
 jump on
 and as I said before, it's not terribly difficult to do, but it will
 take some time.

Do we? Where's that code?

/O

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Fixing Asterisk DNS - bug 9152, asynchronous DNS, etc

[Russell Bryant]

Olle E Johansson wrote:
 21 jun 2007 kl. 18.08 skrev Russell Bryant:
 We already have an asynchronous DNS handler.  It's just that most  
 of the
 code hasn't been converted to use it.  It is open for anyone to  
 jump on
 and as I said before, it's not terribly difficult to do, but it will
 take some time.
 
 Do we? Where's that code?

implementation: main/dnsmgr.c
example usage: channels/chan_iax2.c

-- 
Russell Bryant
Software Engineer
Digium, Inc.

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Polycom SIP Issue bug id 0009335

[Olle E Johansson]

9 apr 2007 kl. 22.37 skrev Timothy McKee:

I have collected the requested data and posted it against bug id  
9335.This issue appears to manifest when asterisk is part of  
the INVITE to a polycom phone and the latency exceeds the 500ms T1  
default timer on the Polycom.  This issue did *not* occur in a much  
older (8/1/04 CVS Head) release with identical configurations.
We've added SIP timer support in Asterisk and times out in a  
different way than the very old CVS versions, so we're propably
much more SIP conformant in that regards now. Try adding qualify=yes  
for the phone, then we'll adjust  Asterisk's timers to the actual

latency.

/Olle
___
--Bandwidth and Colocation provided by Easynews.com --

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

[asterisk-dev] Page program limitation/bug

[Bill Andersen]

I apologize in advance, as I am not a programmer.  I was
hoping someone on this list could just verify that what I
suspect is happening, is in fact happening - possibly by
looking at the source code.

I have 30 Polycom phones on my system and want to be able to do
a Page All.  It appears the Page program has a limit on
the length of the second parameter.  As you can see below, it
truncates the second parameter.  There should be 30 total extensions.

When I page ALL, asterisk -r shows the following...


-- Executing Page(SIP/7112-b40e9410,
Local/[EMAIL PROTECTED]Local/[EMAIL PROTECTED]Loc
al/[EMAIL PROTECTED]Local/[EMAIL PROTECTED]Local/[EMAIL 
PROTECTED]Local/[EMAIL PROTECTED]Local/[EMAIL PROTECTED]
Loc
al/[EMAIL PROTECTED]Local/[EMAIL PROTECTED]Local/[EMAIL 
PROTECTED]Local/[EMAIL PROTECTED]Local/[EMAIL PROTECTED]
Loc
al/[EMAIL PROTECTED]Local/[EMAIL PROTECTED]Local/[EMAIL 
PROTECTED]Local/[EMAIL PROTECTED]) in new stack
Apr  2 15:59:04 WARNING[2167]: app_page.c:193 page_exec: Incomplete
destination
'' supplied.

Only the extensions listed above can hear the page (except 7119 obviously)

Is this just a limitation or a bug?

BA

___
--Bandwidth and Colocation provided by Easynews.com --

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

[asterisk-dev] App_SMS: UDH (EMS) bug and fix

[Anselm Martin Hoffmeister]

Hello everyone,

while setting up a local SMS relay in my asterisk dialplan I found out
that the UDH handling in app_sms does not work as intended. I tracked
that down to app_sms.c code (see below).

Bug description:

On sending a SMS with a UDH (user data header) defined, the appropriate
UDH flag in the SMS first byte will NOT be set currently.
Ref: http://www.dreamfabric.com/sms/deliver_fo.html

Affects:

SMS containing USER DATA HEADERS (e.g. EMS with a bitmap, ringtone,
text formattings or similar embedded to the message)

Location:
=
app_sms.c (1.2.12.1 tarball file apps/app_sms.c, line 1053)
(still present in SVN-trunk (Webaccess) as of today)
 ORIG
   if (h-smsc) {   /* deliver */
   h-omsg[p++] = (more ? 4 : 0);
   p += packaddress (h-omsg + p, h-oa);
   h-omsg[p++] = h-pid;
 CHANGED
   if (h-smsc) {   /* deliver */
   h-omsg[p++] = (more ? 4 : 0) + ((h-udhl  0) ? 0x40 : 0);
   p += packaddress (h-omsg + p, h-oa);
   h-omsg[p++] = h-pid;

Tests:
==
With this additional flag set, it is possible to send EMS with an
embedded picture. Note: replace 12345 with the caller-id to be
displayed, 0193010 with the number of a SMS service center known to
the phone (trailing 1 seems to be necessary) and SIP/sip503 to a
channel where the phone can be reached (mine is a Siemens Gigaset S100
on a ISDN line off a Fritz!Box 7050 as SIP-Client to my asterisk box).

smsq --mt --oa=12345 --mttx-callerid=01930101 --mttx-channel=SIP/sip503
--udh=1121008D000F800FC00FE01FF03FF83FF83FC838C838F838F838F80001 
This is the regular text

This command will display the text and offer to install the supplied
bitmap (which shows a small house, from
http://hjem.get2net.dk/grob/EMS/EMS_samples.html#no3 ) to the phone.

Similar will not work with unpatched app_sms.c, instead a load of
garbage will displayed as SMS text, trailed by This is the regular
text (obviously because the phone has no idea that the beginning of the
SMS contains header data)



I am not a registered asterisk developer and do not have SVN write
access or anything (just subscribed on the -dev mailing list though).
Please tell me how to advance this such that this bug can be fixed.
If this means creating a patch file or so, please tell me to whom to
submit.

Thanks  BR
Anselm

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Hint extension issue - bug?

[Kevin P. Fleming]

- Lucas Alvarez [EMAIL PROTECTED] wrote:
 Hi, I'm using the hint extension to monitoring the status of some 
 extensions. If the extension is defined as a friend, the monitoring 
 doesn't work any more. It only work if I define it as a peer. Is
 that 
 right ? I mean, I supposed that an extension defined as a friend
 should 
 have all the functionality of user and peer types. Is this 
 documented somewhere? How can I know the status of an extension of
 type 
 friend? I hope someone could bring me some light about this issue. 

There is no such thing as an 'extension' defined as a 'friend'. Extensions are 
dialplan entities, and friends are entities in VOIP channel drivers (chan_sip 
and chan_iax2).

To answer your question, no, this should not make any difference. Further 
questions along this line should be sent to the asterisk-users list, since this 
is not a development question.

-- 
Kevin P. Fleming
Senior Software Engineer
Digium, Inc.

___
--Bandwidth and Colocation provided by Easynews.com --

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

[asterisk-dev] Zaptel channel lock bug?

[Anton]

Hello guys!

I'm experiencing the following behaviour on the 
asterisk-1.2.9.1 - suddently one of the lines (the 
secretary, used most oftenly), connected over the T1 
channel banks hangs (just become silent) - until I restart 
asterisk. That happens once in a few days, so it's 
repeatable. Hangs just one line (very rarely more)
Setup is very basic, no complicated routing, no meetme 
usage. Just plain Zaptel-channelbank PBX.

Jul  3 09:31:45 WARNING[14626]: channel.c:787 
channel_find_locked: Avoided deadlock for '0x822cb08', 10 
retries!

is the only suspicious line I can find in the logs. 

when happens, asterisk does not shutdown itself on stop 
now - just silently continues operation - ihave to kill -9 
it.

Does anyone have similar behaviour? Any suggestion what 
types of logs I have to look/swith on to report in more 
detail?

Regards,
Anton.
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Zaptel channel lock bug?

[Paul Cadach]

Hi,


Anton wrote:
 Jul  3 09:31:45 WARNING[14626]: channel.c:787
 channel_find_locked: Avoided deadlock for '0x822cb08', 10
 retries!

Typical deadlock situation. Please, enable locking traces and check what is hold
the lock (where the lock was made).


WBR,
Paul.

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [Asterisk-Dev] res_config_mysql.c connection problems = bug

[Loic DIDELOT]

Hello,
I have for every registration about 3-5 selects and the same thing for
every call. But I only have one update per registration so every 5
minutes I have been able to do 5000 update in 3 seconds on my mysql
server.

Best regards,
Loic Didelot.

On Wed, 2005-11-30 at 01:37 +1300, Matt Riddell wrote:
 Loic DIDELOT wrote:
  ps: i am working on a patch for res_config_mysql.c to send SELECT
  queries and UPDATE queries to 2 different servers (great for
  master-slave database setups). i got it working, except when asterisk
  has connection problems. just give me a sign if anyone is interested in
  reviewing my lousy c code.
 
 Very very interested in this.  I have been pulling my hair out (and I don't
 have much left) trying to figure out how to do it without two way replication,
 so select and update splitting would be great.
 
 What do you think the relationship would be in terms of quantity?  Are there a
 lot more selects than updates?
 

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [Asterisk-Dev] res_config_mysql.c connection problems = bug

[Matt Riddell]

Loic DIDELOT wrote:
 Hello,
 I have for every registration about 3-5 selects and the same thing for
 every call. But I only have one update per registration so every 5
 minutes I have been able to do 5000 update in 3 seconds on my mysql
 server.

Cool, have you got a bug tracker id for the patches?

-- 
Cheers,

Matt Riddell
___

http://www.sineapps.com/news.php (Daily Asterisk News - html)
http://freevoip.gedameurope.com (Free Asterisk Voip Community)
http://www.sineapps.com/rssfeed.php (Daily Asterisk News - rss)

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [Asterisk-Dev] res_config_mysql.c connection problems = bug

[Loic DIDELOT]

Hello,
not really. As this is the first thing I submited ever for a project
I really have no clue how I should submit...

But I tried this: http://bugs.digium.com/view.php?id=5881

Loic




On Wed, 2005-11-30 at 16:03 +1300, Matt Riddell wrote:
 Loic DIDELOT wrote:
  Hello,
  I have for every registration about 3-5 selects and the same thing for
  every call. But I only have one update per registration so every 5
  minutes I have been able to do 5000 update in 3 seconds on my mysql
  server.
 
 Cool, have you got a bug tracker id for the patches?
 

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [Asterisk-Dev] Asterisk or Polycom Bug? - Message waiting

[Rod Dorman]

On Monday, November 7, 2005, 18:25:08, Will McCown wrote:
   ...
 The bad news it that the light remains lit even if there are no
 new messages (as I pretty much expected).  So, it appears that if
 the polycom gets a message-summary with Messages-Waiting: no
 then it ignores the rest of the message and sets all of the counts
 to zero.  Reading the RFC I can see how this might be considered
 the correct behavior.

My  take  on RFC 3842 is that Messages-Waiting: is a 'new' messages flag
only  and  the  presence of 'old' messages are only communicated via the
xxx-Message: lines.

In particular 3.11. Rate of Notifications where it has the phrase
...which do not affect the overall message waiting state
(e.g., there are still new messages).

-- 
[EMAIL PROTECTED] The avalanche has already started, it is too
Rod Dorman  late for the pebbles to vote. – Ambassador Kosh

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

Re: [Asterisk-Dev] Asterisk or Polycom Bug?

[Matt Riddell]

Martin Mateev wrote:
 it's friday night, at least here, get a life

Um...it's Sunday here (5:13am) and I'm still working.

-- 
Cheers,

Matt Riddell
___

http://www.sineapps.com/news.php (Daily Asterisk News - html)
http://freevoip.gedameurope.com (Free Asterisk Voip Community)
http://www.sineapps.com/rssfeed.php (Daily Asterisk News - rss)

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

Re: [Asterisk-Dev] Asterisk or Polycom Bug?

[Kevin P. Fleming]

Will McCown wrote:

We're testing asterisk 1.2 Beta and I've noticed a minor
bug with the message menu on Polycom SIP phones (This is confirmed
with both a IP300 and an IP501 both running 1.4.1).


Why are you using such an old firmware version? The current release is 
1.5.3, and 1.6.2 is about to be released to support the IP601.

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

Re: [Asterisk-Dev] Asterisk or Polycom Bug?

[Tilghman Lesher]

On Friday 04 November 2005 19:21, Martin Mateev wrote:
 it's friday night, at least here, get a life

Unless you're the manager of the person posting, you have no
business regulating when he does his work.

In fact, I'd be interested in hearing about the last thing you
contributed to the Asterisk project.  No, really.  Because if
you're going to criticize someone on the developer's list for
working on Asterisk, you should at least have the credentials
of a developer to back you up.

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

RE: [Asterisk-Dev] Asterisk ethereal plugin bug

[Andreas Sikkema]

 I don't know who the maintainer of the Ethereal plugin is, just
 hoping that he/she is reading this mailinglist, so the bug can be
 addressed. 

You might want to also notify the Ethereal developers. 

ethereal-dev@ethereal.com

-- 
Andreas SikkemaRits tele.com
Van Vollenhovenstraat 33016 BE Rotterdam
t: +31 (0)10 2245544  f: +31 (0)10 413 65 45
___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Asterisk ethereal plugin bug

[Russell Bryant]

Armijn Hemel wrote:
 I don't know who the maintainer of the Ethereal plugin is, just hoping
 that he/she is reading this mailinglist, so the bug can be addressed.

Kenny Shumard, the same person who is working on the IAX2 specification,
recently submitted updates to the IAX2 discector for ethereal.  You
should try grabbing the latest version from their cvs (or whatever they
use) and see if it happens to fix your problem.

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

[Asterisk-Dev] Manager Redirect - Possible bug ?

[Umar Sear]

Hi there, 

I have being trying to use the Manager API redirect command. 

I have done so with initial sucess, however if I try and redirect an
already redirected channel the far end (calling party) is never sent
an update invite with updated SDP and as a consequence does not hear
anything.

I am using purely SIP and here is a bit more detail.

1. 123456  Calls and is put into a queue
2. I use the manager interface to redirect the call to a SIP phone, sayy 8339
3. Call gets redirected. If 8339 answers, all is well so far. 
4. If I now use the manager API to put the caller on hold (transfer to
an extension 876), the calling party heres no MOH

Redirecting again to 8339 works fine. Looking at ethereal traces it
appears that after step 4 although the cli shows that the call has
been successfully redirected to extension 876 and HOH is started, the
calling party (123456) is still sending RTP to 8339, this is because
it never received intstructions to stop sending.

Is this a bug, or am I missing something. 

Relevant parts of my extensions.conf are reproduced below.

exten = 8339,1,Dial(SIP/8339)

exten = 876,1,Answer
exten = 876,2,MusicOnHold(Default)

Note : If Initially redirect to 876 in the first place, that works and
caller hears music on hold.

Please reply with comments, so that if this is a bug I can raise it as such. 

Thanks

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

RE: [Asterisk-Dev] is this a bug?

[Tuyan Ozipek]

#mpg123 -v

High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3.
Version 0.59r (1999/Jun/15). 



On Wed, 2005-01-26 at 07:14, Kenneth Long wrote:
 --- Tuyan Ozipek [EMAIL PROTECTED] wrote:
 
  yesterdays cvs-stable *without* any patchs
  
  Asterisk Ready.
  Asterisk Malloc Debugger Started (see
  /var/log/asterisk/mmlog)
  Beginning asterisk shutdown
  Beginning asterisk shutdown
  Executing last minute cleanups
== Destroying any remaining musiconhold processes
  Jan 26 01:40:09 DEBUG[9342]: res_musiconhold.c:644
  ast_moh_destroy:
  killing 9348!
  Ouch ... error while writing audio data: : Broken
  pipe
  Segmentation fault
  
  seems to be a moh/mpg321 related *crash*
  
  
 mine:
 bash-2.05b$ mpg123 --version
 Version 0.59s-r9 (2000/Oct/27)
 bash-2.05b$ 
 
 I got a compile warning about having the wrong
 release... r9 instead of not having r9
 
 
 
   
 __ 
 Do you Yahoo!? 
 Meet the all-new My Yahoo! - Try it today! 
 http://my.yahoo.com
 
 
 ___
 Asterisk-Dev mailing list
 Asterisk-Dev@lists.digium.com
 http://lists.digium.com/mailman/listinfo/asterisk-dev
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
Tuyan Ozipek [EMAIL PROTECTED]

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

RE: [Asterisk-Dev] is this a bug?

[Brian West]

-c  Provide console CLI

bkw

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:asterisk-dev-
 [EMAIL PROTECTED] On Behalf Of Andrew Kohlsmith
 Sent: Tuesday, January 25, 2005 12:42 PM
 To: Asterisk Developers Mailing List
 Subject: Re: [Asterisk-Dev] is this a bug?
 
 On January 25, 2005 12:59 pm, Steven Critchfield wrote:
  Ctrl-c is actually an interupt. Windows users needed easy to remember
  shortcuts, thats why you are used to ctrl-c.
 
 Yes but why does ^C only interrupt asterisk when -c (colour) is given?  To
 me
 this is a bug.  Asterisk should either always trap these key sequences or
 always pass them, irrespective of your desire to see coloured console
 messages.
 
 -A.
 ___
 Asterisk-Dev mailing list
 Asterisk-Dev@lists.digium.com
 http://lists.digium.com/mailman/listinfo/asterisk-dev
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev

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

RE: [Asterisk-Dev] is this a bug?

[Brian West]

The same reason when you do more somefile and ctrl C exits that too.

bkw

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:asterisk-dev-
 [EMAIL PROTECTED] On Behalf Of Andrew Kohlsmith
 Sent: Tuesday, January 25, 2005 12:39 PM
 To: 'Asterisk Developers Mailing List'
 Subject: Re: [Asterisk-Dev] is this a bug?
 
 On January 25, 2005 12:57 pm, Brian West wrote:
  No its not a bug.. it will always do that if you start it with -c
 
 It's not a bug that enabling colour will allow asterisk to die with ^C,
 ^S??
 If it's not a bug then why does ^C, ^S, etc. not cause * to die?
 
 i.e. why does enabling colour enable these particular crashes?  This
 doesn't
 seem to be the kind of undocumented feature that is conducive to a good
 environment.  :-)
 
 -A.
 ___
 Asterisk-Dev mailing list
 Asterisk-Dev@lists.digium.com
 http://lists.digium.com/mailman/listinfo/asterisk-dev
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev

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

Re: [Asterisk-Dev] is this a bug?

[Rob Gagnon]

Umm...   -c is not for color...
It is for console connection.  Please check your documentation.
- Original Message - 
From: Andrew Kohlsmith [EMAIL PROTECTED]
To: Asterisk Developers Mailing List asterisk-dev@lists.digium.com
Sent: Tuesday, January 25, 2005 12:41 PM
Subject: Re: [Asterisk-Dev] is this a bug?


On January 25, 2005 12:59 pm, Steven Critchfield wrote:
Ctrl-c is actually an interupt. Windows users needed easy to remember
shortcuts, thats why you are used to ctrl-c.
Yes but why does ^C only interrupt asterisk when -c (colour) is given?  To 
me
this is a bug.  Asterisk should either always trap these key sequences or
always pass them, irrespective of your desire to see coloured console
messages.

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

Re: [Asterisk-Dev] is this a bug?

[Eric Wieling]

Andrew Kohlsmith wrote:
On January 25, 2005 12:59 pm, Steven Critchfield wrote:
Ctrl-c is actually an interupt. Windows users needed easy to remember
shortcuts, thats why you are used to ctrl-c.

Yes but why does ^C only interrupt asterisk when -c (colour) is given?  To me 
this is a bug.  Asterisk should either always trap these key sequences or 
always pass them, irrespective of your desire to see coloured console 
messages.
As you can see -c means CONSOLE, not COLOR.
[EMAIL PROTECTED] root]# asterisk -rh
Asterisk CVS-v1-0-12/08/04-11:02:07, Copyright (C) 2000-2004, Digium.
Usage: asterisk [OPTIONS]
Valid Options:
   -V  Display version number and exit
   -C configfile Use an alternate configuration file
   -G group  Run as a group other than the caller
   -U user   Run as a user other than the caller
   -c  Provide console CLI
   -d  Enable extra debugging
   -f  Do not fork
   -g  Dump core in case of a crash
   -h  This help screen
   -i  Initializie crypto keys at startup
   -n  Disable console colorization
   -p  Run as pseudo-realtime thread
   -q  Quiet mode (supress output)
   -r  Connect to Asterisk on this machine
   -R  Connect to Asterisk, and attempt to reconnect if 
disconnected
   -t  Record soundfiles in /tmp and move them where they 
belong after they are done.
   -v  Increase verbosity (multiple v's = more verbose)
   -x cmdExecute command cmd (only valid with -r)

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

Re: [Asterisk-Dev] is this a bug?

[Tilghman Lesher]

On Tuesday 25 January 2005 12:52, Kenneth Long wrote:
 thanks... but this is not the point I'm really
 asking... copying is not the issue...

 I'm worried about the invalid pointer message.

 The ctrl-c crashes Asterisk in xterm.

 I wish such commands would not so easily crash it.

 Is the crash normal behavior?

It's not a crash; it's an interrupt.  You specifically asked Asterisk to
interrupt, and Asterisk obeyed.  If you would like to set another key
to be terminal interrupt, you can.  For example,

bash$ stty intr ^

will change the interrupt key from Ctrl-C to ^, which might be something
you'd be less likely to use.  To change it back without exiting, type:
'stty intr Ctrl-VCtrl-C'

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

Re: [Asterisk-Dev] is this a bug?

[Chris Wade]

Andrew Kohlsmith wrote:
On January 25, 2005 12:59 pm, Steven Critchfield wrote:
Ctrl-c is actually an interupt. Windows users needed easy to remember
shortcuts, thats why you are used to ctrl-c.

Yes but why does ^C only interrupt asterisk when -c (colour) is given?  To me 
this is a bug.  Asterisk should either always trap these key sequences or 
always pass them, irrespective of your desire to see coloured console 
messages.
Did any of you actually check what -c does?  It runs asterisk in console 
mode providing a CLI instead of daemon mode where it immediately forks 
itself away from the controlling terminal.  If you run asterisk with -c 
it MUST (read should according to standards) behave like any other linux 
process terminal and respond in some way to ^C (in fact if it doesn't 
itself, linux will - by killing the process).  And as for what * does 
when it sees ^C, it doesn't die with any error other than a message from 
its input handling routines saying input was interrupted (which is what 
^C is by the way - an INTERRUPT).

So exactly why is this a bug?
-Chris
PS. below is the 'asterisk -h' from CVS-HEAD, notice the only mention of 
color is the '-n' option, not the '-c' option :)

Asterisk CVS-HEAD-01/24/05-10:35:33, Copyright (C) 2000 - 2005, Digium.
Usage: asterisk [OPTIONS]
Valid Options:
   -V  Display version number and exit
   -C configfile Use an alternate configuration file
   -G group  Run as a group other than the caller
   -U user   Run as a user other than the caller
   -c  Provide console CLI
   -d  Enable extra debugging
   -f  Do not fork
   -g  Dump core in case of a crash
   -h  This help screen
   -i  Initialize crypto keys at startup
   -n  Disable console colorization
   -p  Run as pseudo-realtime thread
   -q  Quiet mode (suppress output)
   -r  Connect to Asterisk on this machine
   -R  Connect to Asterisk, and attempt to reconnect if 
disconnected
   -t  Record soundfiles in /var/tmp and move them where 
they belong after they are done.
   -v  Increase verbosity (multiple v's = more verbose)
   -x cmdExecute command cmd (only valid with -r)

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

Re: [Asterisk-Dev] is this a bug?

[Tilghman Lesher]

On Tuesday 25 January 2005 12:39, Andrew Kohlsmith wrote:
 On January 25, 2005 12:57 pm, Brian West wrote:
  No its not a bug.. it will always do that if you start it with -c

 It's not a bug that enabling colour will allow asterisk to die with
 ^C, ^S?? If it's not a bug then why does ^C, ^S, etc. not cause * to
 die?

 i.e. why does enabling colour enable these particular crashes?  This
 doesn't seem to be the kind of undocumented feature that is
 conducive to a good environment.  :-)

c is for console, not for color (see the output of 'asterisk -h').  As
the process is running in the foreground, Ctrl-C naturally interrupts
the foreground process.  Note that if you start asterisk in the
background (i.e. without the -c option or with a startup script), then
connect to it with -r or -R, Ctrl-C will not exit the main asterisk
process, but only the remote console.  Here ends the -user lesson on the
-dev list.

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

RE: [Asterisk-Dev] is this a bug?

[Brian West]

I start asterisk with asterisk -vgc

I press ctrl-c 

I get

*CLI Beginning asterisk shutdown
Beginning asterisk shutdown
Killed

bkw

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:asterisk-dev-
 [EMAIL PROTECTED] On Behalf Of Kenneth Long
 Sent: Tuesday, January 25, 2005 12:53 PM
 To: Asterisk Developers Mailing List
 Subject: Re: [Asterisk-Dev] is this a bug?
 
 thanks... but this is not the point I'm really
 asking... copying is not the issue...
 
 I'm worried about the invalid pointer message.
 
 The ctrl-c crashes Asterisk in xterm.
 
 I wish such commands would not so easily crash it.
 
 Is the crash normal behavior?
 
 
 regards,
 Ken
 
 
 --- Steven Critchfield [EMAIL PROTECTED] wrote:
 
  Hello -user question from a windows user.
 
  On Tue, 2005-01-25 at 09:14 -0800, Kenneth Long
  wrote:
   I'm launching Asterisk on a xterm session.
   I wanted to highlight some text and out of
   habit I did a ctrl-C. That reliably and
  consistantly
   shuts down Asterisk with a invalid pointer.
   Same error message everytime.
 
  Ctrl-c is actually an interupt. Windows users needed
  easy to remember
  shortcuts, thats why you are used to ctrl-c.
 
   Some other Ctrl- key sequences lock the session,
  too.
   like ctrl-S.
 
  From terminal days, ctrl-s is flow control stop.
  ctrl-q is what you use
  to restart from a ctrl-s.
 
  Most terminals should automatically copy on select.
  You will find unix
  traditions are full of as short as can be short
  cuts. Select implies
  copy and middle click pastes. Click select click and
  your done.
  --
  Steven Critchfield [EMAIL PROTECTED]
 
  ___
  Asterisk-Dev mailing list
  Asterisk-Dev@lists.digium.com
 
 http://lists.digium.com/mailman/listinfo/asterisk-dev
  To UNSUBSCRIBE or update options visit:
 
 
 http://lists.digium.com/mailman/listinfo/asterisk-dev
 
 
 
 
 
 __
 Do you Yahoo!?
 Yahoo! Mail - Helps protect you from nasty viruses.
 http://promotions.yahoo.com/new_mail
 ___
 Asterisk-Dev mailing list
 Asterisk-Dev@lists.digium.com
 http://lists.digium.com/mailman/listinfo/asterisk-dev
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev

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

Re: [Asterisk-Dev] is this a bug?

[Andrew Kohlsmith]

On January 25, 2005 02:54 pm, Eric Wieling wrote:
 As you can see -c means CONSOLE, not COLOR.

Then why does asterisk -vvg spit up a CLI, and asterisk -vvgc spit 
up the same CLI in colour?  :-)

I will admit that lacking a '-c' does not give me a CLI, but it also gives me 
colour output.

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

Re: [Asterisk-Dev] is this a bug?

[Andrew Kohlsmith]

Please don't post with HTML, **ESPECIALLY** in the -dev list.

On January 25, 2005 02:35 pm, Alexander Lopez wrote:
 ^c. = interrupt
 ^d = eof
 Etc

I've been using Unix for 10 years, I know what they mean.  I am saying that if 
they *don't* cause * to crash without -c, why do they cause * to crash with 
-c...  also why are they not being trapped and handled properly instead of 
literally crashing the server.

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

Re: [Asterisk-Dev] is this a bug?

[Steven Critchfield]

On Tue, 2005-01-25 at 10:52 -0800, Kenneth Long wrote:
 thanks... but this is not the point I'm really
 asking... copying is not the issue...
 
 I'm worried about the invalid pointer message.  
 
 The ctrl-c crashes Asterisk in xterm. 
 
 I wish such commands would not so easily crash it.
 
 Is the crash normal behavior?

Asterisk isn't so much crashing as not eloquently exiting. By sending
ctrl-c to asterisk, you are actually asking it to quit.

While I cringe when I ave to use it, when you have connected to asterisk
with asterisk -r, you have to use ctrl-c to exit the connection. The
trouble basically being that you are then using the asterisk executable
as a specialized communications tool.



 --- Steven Critchfield [EMAIL PROTECTED] wrote:
 
  Hello -user question from a windows user.
  
  On Tue, 2005-01-25 at 09:14 -0800, Kenneth Long
  wrote:
   I'm launching Asterisk on a xterm session.
   I wanted to highlight some text and out of
   habit I did a ctrl-C. That reliably and
  consistantly
   shuts down Asterisk with a invalid pointer.
   Same error message everytime.
  
  Ctrl-c is actually an interupt. Windows users needed
  easy to remember
  shortcuts, thats why you are used to ctrl-c. 
  
   Some other Ctrl- key sequences lock the session,
  too.
   like ctrl-S.
  
  From terminal days, ctrl-s is flow control stop.
  ctrl-q is what you use
  to restart from a ctrl-s.
  
  Most terminals should automatically copy on select.
  You will find unix
  traditions are full of as short as can be short
  cuts. Select implies
  copy and middle click pastes. Click select click and
  your done.
  -- 
  Steven Critchfield [EMAIL PROTECTED]
  
  ___
  Asterisk-Dev mailing list
  Asterisk-Dev@lists.digium.com
 
 http://lists.digium.com/mailman/listinfo/asterisk-dev
  To UNSUBSCRIBE or update options visit:

 
 http://lists.digium.com/mailman/listinfo/asterisk-dev
  
 
 
 
   
 __ 
 Do you Yahoo!? 
 Yahoo! Mail - Helps protect you from nasty viruses. 
 http://promotions.yahoo.com/new_mail
 ___
 Asterisk-Dev mailing list
 Asterisk-Dev@lists.digium.com
 http://lists.digium.com/mailman/listinfo/asterisk-dev
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
Steven Critchfield [EMAIL PROTECTED]

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

Re: [Asterisk-Dev] is this a bug?

[Steve Clark]

Alexander Lopez wrote:
^c. = interrupt
^d = eof
Etc
-Original Message-
From: [EMAIL PROTECTED] 
[EMAIL PROTECTED]
To: 'Asterisk Developers Mailing List' asterisk-dev@lists.digium.com
Sent: Tue Jan 25 13:39:01 2005
Subject: Re: [Asterisk-Dev] is this a bug?

On January 25, 2005 12:57 pm, Brian West wrote:
  No its not a bug.. it will always do that if you start it with -c
It's not a bug that enabling colour will allow asterisk to die with 
^C, ^S??
If it's not a bug then why does ^C, ^S, etc. not cause * to die?
-c Provide  a  control console on the calling terminal.  Specifying
  this option implies -f and will cause asterisk to no longer fork
  or detach from the controlling terminal.
-c has nothing to do with colour. See above.
The CTL-c send an SIG-INT to the process thus killing it. Don't use the -c and 
this won't happen. You can connect to the asterisk that is running as a daemon 
by using asterisk -r.

HTH,
Steve
--
They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety.  (Ben Franklin)
The course of history shows that as a government grows, liberty
decreases.  (Thomas Jefferson)
___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[Asterisk-Dev] app_dial - Feature or bug ?

[Umar Sear]

Hi,

I have an Agi script that uses the app_dial to setup
calls. After the call is terminated I do some clean up
work updating records using information about the call
from the CDR etc. 

All of this works well except when the called party
hangs up. In this case my script exists before the CDR
record is populated. 

Is this expected behaviour. Any comments ?
suggesstions.

Thanks

Umar.





___ALL-NEW Yahoo! Messenger - 
so many all-new ways to express yourself http://uk.messenger.yahoo.com
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Bug 14 in bug tracker (fwd)

[Chris Heiser]

Mark,

FYI...

X-ten has e-mailed me and are working to resolve this odd implementation in
X-lite (I presume they'll check X-pro) so that it follows the RFC.  This is
the first DTMF problem I've come across where the duration field was the
problem.  Most issues I've seen have to do with the Sip endpoint ignoring
the SDP info from Asterisk.

--Chris Heiser

- Original Message -
From: Mark Spencer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, July 25, 2003 1:57 PM
Subject: RE: [Asterisk-Dev] Bug 14 in bug tracker (fwd)


 It's a little of both probably.  Asterisk's handling of DTMF in RTP isn't
 proper either -- it is made around an attempt to be robust in handling
 good implementations, but that makes it sensitive to odd implementations.

 Mark

 On Fri, 25 Jul 2003, Peter Grace wrote:

  I've done a workaround in rtp.c, but I know I'd prefer for the
  solution to be concrete.  What exactly is wrong, so we can give the
  xten people a good idea of what needs to be done?  From your message I
  gather that the duration field is not being properly populated?
 
  On Fri, 25 Jul 2003, Chris Heiser wrote:
 
   This actually appears to be a bug with the X-Lite Sip Phone.
   I've done some packet captures, and the X-Lite violates RFC2833.
  
   For the Payload of the RTP packet for DTMF, the RFC states:
  
  duration: Duration of this digit, in timestamp units. Thus, the
  event began at the instant identified by the RTP timestamp
  and has so far lasted as long as indicated by this
parameter.
  The event may or may not have ended.
  
   X-Lite never increments the duration field of the RTP packets for DTMF
   digits.  I'm sure this is confusing Asterisk.  I'd say e-mail the
X-Lite
   folks and tell them they have bugs.
  
   --Chris Heiser
  
-Original Message-
From: [EMAIL PROTECTED] [mailto:asterisk-dev-
[EMAIL PROTECTED] On Behalf Of Chris Heiser
Sent: Thursday, July 24, 2003 6:47 PM
To: [EMAIL PROTECTED]
Subject: Re: [Asterisk-Dev] Bug 14 in bug tracker (fwd)
   
Peter,
   
Can you send a tcpdump of the session between asterisk and the
X-lite
phone?
   
Something like: tcpdump -s 0 -w xlite-phone-dump host [x-lite ip
address]
Make sure you run it while you're not logged in or otherwise
connected to
Asterisk (so the tcpdump only has the packets between the X-lite
phone and
Asterisk)
   
I'd say just e-mail it to me direct as the file will probably be a
little
big to go out on the mailing list.
I've had to debug other DTMF issues with other devices.  (I've come
across
a
few sip UA's that ignore the SDP info that Asterisk sends out).
Maybe I
can
be of some help.
   
--Chris Heiser
   
- Original Message -
From: Peter Grace [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 24, 2003 3:54 PM
Subject: [Asterisk-Dev] Bug 14 in bug tracker (fwd)
   
   
 Oops.  Helps if you have the list address right.. See below!

 -- Forwarded message --
 Date: Thu, 24 Jul 2003 15:04:44 -0400 (EDT)
 From: Peter Grace [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Bug 14 in bug tracker

 Guys,

 I just fired in a bug report, but I'll give the rundown:

 http://bugs.digium.com/bug_view_page.php?bug_id=014


 X-Lite's DTMF problems with voicemail may not be X-lite's fault...
I
was
 tracking DTMF between rtp.c and channel.c and it looks like the
system
is
 ignoring the first couple digits.  Check the bug report for full
debug
 messages...

 Thanks,
 Pete

 ___
 Asterisk-Dev mailing list
 [EMAIL PROTECTED]
 http://lists.digium.com/mailman/listinfo/asterisk-dev

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
   ___
   Asterisk-Dev mailing list
   [EMAIL PROTECTED]
   http://lists.digium.com/mailman/listinfo/asterisk-dev
  
  ___
  Asterisk-Dev mailing list
  [EMAIL PROTECTED]
  http://lists.digium.com/mailman/listinfo/asterisk-dev
 

 ___
 Asterisk-Dev mailing list
 [EMAIL PROTECTED]
 http://lists.digium.com/mailman/listinfo/asterisk-dev

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Zap show channels bug?

[Pertti Pikkarainen]

'show channels'  has also a problem related to this. It is very often 
showing wrong numbers.
Those are numbers that have been active some time earlier.
And these are the same incorrect extension numbers that 'zap show 
channels' show.

In other words ...
When you see numbers in inactive channels with 'zap show channels',
you can expect to see those incorrectly in 'show channels' as well.
--Pertti

Mark Spencer wrote:

Actually, zap show channels was Matt Fredrickson's project before he
left for his Mormon mission.  He should be finishing his two year mission
next March, so it might get completed then, or possibly earlier if someone
wants to actually determine what would be useful info to display and make
a patch :)
Mark

On 1 Jul 2003, Steven Critchfield wrote:

 

Just so you know you aren't alone. I have similar things happening on my
system. I'm not sure how useful it is. I have used it to see what my
high water mark is.
I'm guessing in channels/chan_zap.c around either line 1590 or 1680
there needs to be a line added to set p-exten = NULL.
Steven

On Tue, 2003-07-01 at 17:13, John Todd wrote:
   

This odd output has always been the case on my particular systems,
and only now am I starting to think that something is amiss with the
zap show channels display:
gw3*CLI zap show channels
Chan. Num. Extension  ContextLanguage   MusicOnH
  1 1410985012 pri-inboun
  2 1410985012 pri-inboun
  3 1301531972 pri-inboun
  4 1410985012 pri-inboun
  5 1410985012 pri-inboun
  6pri-inboun
  7pri-inboun
  8pri-inboun
  9pri-inboun
 10pri-inboun
 11pri-inboun
 12pri-inboun
 13pri-inboun
 14pri-inboun
 15pri-inboun
 16pri-inboun
 17pri-inboun
 18pri-inboun
 19pri-inboun
 20pri-inboun
 21pri-inboun
 22pri-inboun
 23pri-inboun
gw3*CLI
There are _no_ active channels on this PRI (yes, I am _absolutely_
sure.)   This output, however, is confusing - why does it show that
certain Zap channels have calls?  When there is a call on Zap/1-1,
the output is identical.
JT
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
 

--
Steven Critchfield [EMAIL PROTECTED]
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
   

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
 



___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev

[Asterisk-Dev] annoyance, not necessarily bug in SIP

[Steven Critchfield]

On my home machine when I restart asterisk I have 2 messages pop up
shortly after the startup messages finish. 
WARNING[81926]: File chan_sip.c, Line 409 (retrans_pkt): Maximum retries
exceeded on call [EMAIL PROTECTED] for seqno
102 (Request)

WARNING[81926]: File chan_sip.c, Line 409 (retrans_pkt): Maximum retries
exceeded on call [EMAIL PROTECTED] for seqno
102 (Request)

I do not have any SIP hardware on my network, nor anything calling in. I
think I might put a noload in the modules.conf later. Just thought
someone might like to see this.

-- 
Steven Critchfield  [EMAIL PROTECTED]

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev