gmane.comp.telephony.pbx.asterisk.devel

Re: "Sending Complete" IE status availability ?

Pavel Troller — 2012-05-25T04:24:56

Hi Richard!


Thank you for your response.
Because I need it in the dialplan to know, whether the dialling is finished
for sure or not, I've written a simple patch, which adds parameter called
"sending_complete_received" to the CHANNEL() core function, so for example
the following is now working for me:

[macro-pri-sethashed]

exten => s,1,GotoIf($["${CHANNEL(channeltype)}" != "DAHDI"]?nodahdi)
exten => s,n,GotoIf($["${CHANNEL(dahdi_type)}" != "pri"]?nodahdi)
exten => s,n,GotoIf($["${CHANNEL(sending_complete_received)}" = "0"]?nodahdi)
exten => s,n,Log(WARNING,"Setting HASHED")
exten => s,n,Set(HASHED="y")
exten => s,n(nodahdi),MacroExit()

Thanks to this, the variable HASHED may be set in the dialplan. This variable
is used generally through the dialplan to determine, whether the dial string is
to be considered complete (for example, in my handling of SS7 calls it is
being set if the number ends with a "F" digit, which has also the meaning
of "Sending Complete" status).

Do you think this extension could be merged into the official Asterisk 
sources ? If yes, I will improve it a bit (for example, the new parameter
is not yet mentioned in the help text) and post the patch to the review
board. Now it's just 7 lines added.


Thank you for the explanation, I found all the occurences after your notice.


With regards, Pavel

--
_____________________________________________________________________

Re: [Code Review] Add documentation to function CHANNEL for options echocan_mode and buffers

elguero — 2012-05-25T03:34:09

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

(Updated May 24, 2012, 10:34 p.m.)


Review request for Asterisk Developers.


Changes
-------

Fix typo in description.


Summary (updated)
-------

It looks like the setting of "echocan_mode" and "buffers" through the dialplan was added to chan_dahdi some time ago.  This patch adds some documentation to func_channel.


This addresses bug ASTERISK-19911.
    https://issues.asterisk.org/jira/browse/ASTERISK-19911


Diffs
-----

  /branches/1.8/funcs/func_channel.c 367732 

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


Testing
-------

Local dev machine.


Thanks,

elguero

--
_____________________________________________________________________

[Code Review] Add documentation to function CHANNEL for options echocan_mode and buffers

elguero — 2012-05-25T03:27:52

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

Review request for Asterisk Developers.


Summary
-------

It looks setting "echocan_mode" and "buffers" through the dialplan was added to chan_dahdi some time ago.  This patch adds some documentation to func_channel.


This addresses bug ASTERISK-19911.
    https://issues.asterisk.org/jira/browse/ASTERISK-19911


Diffs
-----

  /branches/1.8/funcs/func_channel.c 367732 

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


Testing
-------

Local dev machine.


Thanks,

elguero

--
_____________________________________________________________________

asterisk.org documentation

Paul Belanger — 2012-05-24T22:06:58

Can we please remove the documentation from asterisk.org[1]?  It is old 
an out-dated. New asterisk users are using it and getting frustrated 
when it does not work.

For example, here is what google still returns[2].

[1] http://www.asterisk.org/astdocs/asterisk.html
[2] https://www.google.ca/#q=site:asterisk.org+astdocs

Re: [Code Review] Patch to detect/parse ANI-II / ANI2 / OLI from SIP INVITE messages

rmudgett — 2012-05-24T21:42:47

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



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1947/#comment11810>

    Opening curly on a function goes on a line by itself.


- rmudgett


On May 24, 2012, 3:20 p.m., Rob Gagnon wrote:

--
_____________________________________________________________________

Re: [Code Review] logger: Call ID logging phase III part 1 split - chan_iax2 and chan_dahdi

jrose — 2012-05-24T21:36:36

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



/trunk/channels/sig_pri.c
<https://reviewboard.asterisk.org/r/1927/#comment11809>

    All of this changing c to chan stuff can go since I ended up not doing anything here.


- jrose


On May 24, 2012, 4:32 p.m., jrose wrote:

--
_____________________________________________________________________

Re: [Code Review] logger: Call ID logging phase III part 1 split - chan_iax2 and chan_dahdi

jrose — 2012-05-24T21:32:09

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

(Updated May 24, 2012, 4:32 p.m.)


Review request for Asterisk Developers, rmudgett and Matt Jordan.


Changes
-------

Addresses Richard's comments, adds autoservice thread binding, chan_agent, chan_local, and stuff to handle the signalling stuff in chan_dahdi.


Summary
-------

split from: https://reviewboard.asterisk.org/r/1886/
These changes allow channels dahdi and iax2 to set callids and bind log messages to callids.

This is the same code as in the earlier review.  It was split to commit the approved parts and to hopefully encourage some review of the remaining parts since there is less in here to review now.


Diffs (updated)
-----

  /trunk/channels/chan_agent.c 367420 
  /trunk/channels/chan_dahdi.c 367420 
  /trunk/channels/chan_iax2.c 367420 
  /trunk/channels/chan_local.c 367420 
  /trunk/channels/sig_analog.c 367420 
  /trunk/channels/sig_pri.c 367420 
  /trunk/main/autoservice.c 367420 
  /trunk/main/logger.c 367420 
  /trunk/main/pbx.c 367420 

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


Testing
-------

see https://reviewboard.asterisk.org/r/1886/


Thanks,

jrose

--
_____________________________________________________________________

Re: [Code Review]: Improve SDP parsing warningmessages and RFC compliance

Kevin Fleming — 2012-05-24T21:16:30



No, it got moved up into the media-type specific sections, so the warning message generated can be more specific (like all the others are).



Reverted.


- Kevin


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


On May 24, 2012, 4:15 p.m., Kevin Fleming wrote:

--
_____________________________________________________________________

Re: [Code Review] Improve SDP parsing warningmessages and RFC compliance

Kevin Fleming — 2012-05-24T21:15:03

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

(Updated May 24, 2012, 4:15 p.m.)

Review request for Asterisk Developers and opticron.

Changes
-------

Addressed Kinsey's review feedback. There are still some remaining red blobs that I can remove at commit time.

Summary
-------

This patch improves the warning messages generated during SDP parsing when various problems are found:

* 'Unsupported media type' is only reported when that is in fact the case, not when a supported media type is included in an 'm' line that has an invalid format.

* All warning messages related to parsing 'm' lines now include the 'm' line contents.

* (minor bugfix) newline added to port-number-zero warning messages.

* Warning messages improved to use RFC-specified terminology for various items.

* Warnings for offers that include more than port for a single media type now include the media type.

* Nearly all SDP errors will result in a '488 Not Acceptable Here' response, rather than an attempt to use some part of the offer/answer presented in the SDP.

This patch does *not* correct Asterisk's behavior when a media stream offer with a port number of 0 (zero) is received; that will have to be done in another patch.

Diffs (updated)
-----

/branches/1.8/channels/chan_sip.c 367677

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

Testing
-------

Compile testing only.

Thanks,

Kevin

--
_____________________________________________________________________

Re: [Code Review]: Add IAX2 support for the newHANGUPCAUSE hash

rmudgett — 2012-05-24T21:04:01



The "true" value returned by comparisons and other logical operations is 1.  The C standard says so.  It is just not used that way very often.


- rmudgett


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


On May 24, 2012, 3:34 p.m., opticron wrote:

--
_____________________________________________________________________

Re: "Sending Complete" IE status availability ?

Richard Mudgett — 2012-05-24T20:56:03

No.  The sending complete flag is not saved and is not made available
to the dialplan.


The sending complete flag is used three times.  The first is for the
"s" extension.  The second is in determining what response message to send
(PROCEEDING/ANSWER/SETUP-ACKNOWLEDGE).  The third is to determine if the
pri_ss_thread needs to be started to gather more digits for a dialplan
extension match.

Richard

--
_____________________________________________________________________

Re: [Code Review] Add tests for the IAX2 implementation of the HANGUPCAUSE hash

Mark Michelson — 2012-05-24T20:41:13

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

Ship it!


Looks like this'll do the trick!

- Mark


On May 22, 2012, 8:33 a.m., opticron wrote:

--
_____________________________________________________________________

Re: [Code Review] Add IAX2 support for the newHANGUPCAUSE hash

opticron — 2012-05-24T20:34:15

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

(Updated May 24, 2012, 3:34 p.m.)


Review request for Asterisk Developers.


Changes
-------

Addressed Mark's concerns about embedding boolean expressions directly into arithmetic.


Summary
-------

Add the IAX2 implementation of the "Who Hung Up?" work for Asterisk 11.  Numeric cause codes are provided for messages in which they're expected.  Additionally, methods of generating descriptions of frame types and subclasses have been exposed.


This addresses bug SWP-4222.
    https://issues.asterisk.org/jira/browse/SWP-4222


Diffs (updated)
-----

  trunk/channels/chan_iax2.c 367194 
  trunk/include/asterisk/frame.h 367194 
  trunk/main/frame.c 367194 

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


Testing
-------

See tests in Review 1942.


Thanks,

opticron

--
_____________________________________________________________________

Re: [Code Review]: Add IAX2 support for the newHANGUPCAUSE hash

opticron — 2012-05-24T20:34:09



I'll look into it after this goes in.



Addressed.


- opticron


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


On May 22, 2012, 8:32 a.m., opticron wrote:

--
_____________________________________________________________________

Re: [Code Review] Patch to detect/parse ANI-II / ANI2 / OLI from SIP INVITE messages

Rob Gagnon — 2012-05-24T20:20:32

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

(Updated May 24, 2012, 3:20 p.m.)


Review request for Asterisk Developers, Mark Michelson and Rob Gagnon.


Changes
-------

Fixing jira link


Summary
-------

Add ANI2 / OLI parsing for SIP.  The patch checks the "From" header during the handle_request_invite() function for the presence of "isup-oli", "ss7-oli", or "oli" tags.  If present, the up-to-2-digits following the equal sign in the tag are set on the channel's caller structure in the "ani2" int element.

This allows SIP functions that reference ANI2 to work properly for SIP.  Specifically tested was the messaging that occurs when AGI transmits its data to an AGI script.


This addresses bug ASTERISK-19912.
    https://issues.asterisk.org/jira/browse/ASTERISK-19912


Diffs
-----

  /trunk/channels/chan_sip.c 367677 

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


Testing
-------

Call processing via AGI call in dial plan which logs all AGI incoming values was executed from cell phone, land line, and payphone.  During the payphone call, the value of "agi_callingani2" was properly transmitted as "7" while the others were "0"


Thanks,

Rob

--
_____________________________________________________________________

Re: [Code Review] Patch to detect/parse ANI-II / ANI2 / OLI from SIP INVITE messages

Rob Gagnon — 2012-05-24T20:20:13

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

(Updated May 24, 2012, 3:20 p.m.)


Review request for Asterisk Developers, Mark Michelson and Rob Gagnon.


Changes
-------

Adding Mark


Summary
-------

Add ANI2 / OLI parsing for SIP.  The patch checks the "From" header during the handle_request_invite() function for the presence of "isup-oli", "ss7-oli", or "oli" tags.  If present, the up-to-2-digits following the equal sign in the tag are set on the channel's caller structure in the "ani2" int element.

This allows SIP functions that reference ANI2 to work properly for SIP.  Specifically tested was the messaging that occurs when AGI transmits its data to an AGI script.


This addresses bug 19912.
    https://issues.asterisk.org/jira/browse/19912


Diffs
-----

  /trunk/channels/chan_sip.c 367677 

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


Testing
-------

Call processing via AGI call in dial plan which logs all AGI incoming values was executed from cell phone, land line, and payphone.  During the payphone call, the value of "agi_callingani2" was properly transmitted as "7" while the others were "0"


Thanks,

Rob

--
_____________________________________________________________________

Re: [Code Review]: Patch to detect/parse ANI-II / ANI2 / OLI from SIP INVITE messages

Rob Gagnon — 2012-05-24T20:19:24



Done.  it is now void.  I was thinking we might need a future return value should SIP eventually need to pass OLI through to the B-side, but I can't see a need at this time.



Removed the "if (!s)" piece of code.  This was left over from a test driver I wrote to handle many kinds of "From:" headers to ensure all use-cases I could come up with didn't crash the routine.



I thought of sscanf() and strip quoted as well, but since this was a simple 2-digit search only, I went for processing speed with the manual character manipulation.


- Rob


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


On May 24, 2012, 3:18 p.m., Rob Gagnon wrote:

--
_____________________________________________________________________

Re: [Code Review] Patch to detect/parse ANI-II / ANI2 / OLI from SIP INVITE messages

Rob Gagnon — 2012-05-24T20:18:07

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

(Updated May 24, 2012, 3:18 p.m.)


Review request for Asterisk Developers and Rob Gagnon.


Changes
-------

Changes made (for the most part) using Mark's comments


Summary
-------

Add ANI2 / OLI parsing for SIP.  The patch checks the "From" header during the handle_request_invite() function for the presence of "isup-oli", "ss7-oli", or "oli" tags.  If present, the up-to-2-digits following the equal sign in the tag are set on the channel's caller structure in the "ani2" int element.

This allows SIP functions that reference ANI2 to work properly for SIP.  Specifically tested was the messaging that occurs when AGI transmits its data to an AGI script.


This addresses bug 19912.
    https://issues.asterisk.org/jira/browse/19912


Diffs (updated)
-----

  /trunk/channels/chan_sip.c 367677 

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


Testing
-------

Call processing via AGI call in dial plan which logs all AGI incoming values was executed from cell phone, land line, and payphone.  During the payphone call, the value of "agi_callingani2" was properly transmitted as "7" while the others were "0"


Thanks,

Rob

--
_____________________________________________________________________

Re: [Code Review] Patch to detect/parse ANI-II / ANI2 / OLI from SIP INVITE messages

Mark Michelson — 2012-05-24T19:52:09

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

Ship it!


I've given a ship it! on this because nothing on this review is actually "wrong". These are merely suggestions.


/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1947/#comment11795>

    Since the return value of this function is not actually checked, you may as well have it return void.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1947/#comment11793>

    You can combine this to all be if (ast_strlen_zero) since it checks both for NULL and zero-length strings.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1947/#comment11794>

    This all certainly works, and I'm not going to say this *can't* go in like this, but there are some functions that can help you out here to make things a bit simpler.
    
    s = ast_strip_quoted(s, "\"");
    if (sscanf(s, "%2d", &ani2) == 1) {
        ast_channel_caller(chan)->ani2 = ani2;
    }
    
    The only caveat to this approach is that ast_strip_quoted() modifies the string that you grabbed from the SIP request, so you'd need to change the top line of this function to
    
    char *from = ast_strdupa(sip_get_header(req, "From");


- Mark


On May 24, 2012, 2:39 p.m., Rob Gagnon wrote:

--
_____________________________________________________________________

Re: [Code Review] Patch to detect/parse ANI-II / ANI2 / OLI from SIP INVITE messages

Mark Michelson — 2012-05-24T19:52:24

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

Ship it!


I've given a ship it! on this because nothing on this review is actually "wrong". These are merely suggestions.


/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1947/#comment11796>

    This all certainly works, and I'm not going to say this *can't* go in like this, but there are some functions that can help you out here to make things a bit simpler.
    
    s = ast_strip_quoted(s, "\"");
    if (sscanf(s, "%2d", &ani2) == 1) {
        ast_channel_caller(chan)->ani2 = ani2;
    }
    
    The only caveat to this approach is that ast_strip_quoted() modifies the string that you grabbed from the SIP request, so you'd need to change the top line of this function to
    
    char *from = ast_strdupa(sip_get_header(req, "From");


- Mark


On May 24, 2012, 2:39 p.m., Rob Gagnon wrote:

--
_____________________________________________________________________

[Code Review] Patch to detect/parse ANI-II / ANI2 / OLI from SIP INVITE messages

Rob Gagnon — 2012-05-24T19:39:29

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

Review request for Asterisk Developers and Rob Gagnon.


Summary
-------

Add ANI2 / OLI parsing for SIP.  The patch checks the "From" header during the handle_request_invite() function for the presence of "isup-oli", "ss7-oli", or "oli" tags.  If present, the up-to-2-digits following the equal sign in the tag are set on the channel's caller structure in the "ani2" int element.

This allows SIP functions that reference ANI2 to work properly for SIP.  Specifically tested was the messaging that occurs when AGI transmits its data to an AGI script.


This addresses bug 19912.
    https://issues.asterisk.org/jira/browse/19912


Diffs
-----

  /trunk/channels/chan_sip.c 367655 

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


Testing
-------

Call processing via AGI call in dial plan which logs all AGI incoming values was executed from cell phone, land line, and payphone.  During the payphone call, the value of "agi_callingani2" was properly transmitted as "7" while the others were "0"


Thanks,

Rob

--
_____________________________________________________________________