[asterisk-dev] SMDI on 1.6.0-beta5

[Bill Sofko]

Asterisk Developers Mailing List <asterisk-dev at lists.digium.com> writes:
>Kevin P. Fleming wrote:
>> Bill Sofko wrote:
>> 
>>> If people are interested in working on this, I am happy to provide help
>>> (we can also do some testing on off hours against our production
>switch --
>>> sadly, I don't have a test switch). Additionally, whereas we'll need
>this
>>> for our own use, I can probably work up the necessary patches (though I
>>> don't want to step on any toes) and will need to do so if the community
>>> isn't interested in the functionality I described.
>> 
>> That issue is marked closed as 'fixed' because it is fixed, but it was
>> not fixed by the patches attached to the issue. In fact all the points
>> you raise are valid, and have been addressed.
>> 
>> Instead, the entire SMDI implementation was rewritten, but the
>> doc/smdi.txt file has not been updated to match the new code.
>> 
>> In summary there is no channel-driver SMDI magic any more at all;
>> instead, all SMDI handling (message reading and interpretation of the
>> contents) is done in the dialplan, so the dialplan can create any sort
>> of mapping between incoming channels and SMDI terminal numbers it
>> wishes. In addition, you can receive all SMDI message types and handle
>> them the way that you wish, there is no built-in logic for what to do
>> with different messages. All this work was done to support a customer
>> who has a TDM-to-SIP gateway sitting in front of Asterisk, so they
>> receive the incoming calls from the SMDI-equipped switch over SIP, but
>> the SMDI messages arrive the normal way (over an RS-232 link). In this
>> environment, the timing of the incoming calls and the SMDI messages is
>> even more unpredictable than you have mentioned, so the code had to be
>> changed.
>
>Kevin already did a good job explaining what we did to rework SMDI
>support, so I
>won't go into it any more than that.  :)
>
>However, after looking at this, if you think of any reason that the
>current
>interface will not work for you, please let us know.
>
>> We'll try to get doc/smdi.txt in the trunk and 1.6.0 branches updated
>> soon to show the new way of handling SMDI in the dialplan... stay tuned!
>
>Oops.  I had some information about how to use it, but it was just
>sitting in my
>sent email to the person that it was written for.  I have updated
>doc/smdi.txt
>to include some info on how to access SMDI messages from the dialplan.
>
>http://svn.digium.com/view/asterisk/trunk/doc/smdi.txt?view=markup

Kevin and Russell -

Thank you both for your responses!

I had suspected that some of my understanding was incorrect and am glad to
hear that you think things will work fine for us. I do have one question,
though. What had been confusing me is that the SMDI_MSG_RETRIEVE()
function's second parameter is labelled as <station>. I had initally
thought that this indeed would be the mechanism used to lookup an SMDI
message using the message desk terminal number, but then thought instead
that it probably referred to the forwarding station number (though I
couldn't figure out why one would use that in a dial plan). I didn't have
time to sort through all the ASTOBJ* macros to figure out exactly which
field was being searched and came, apparently, to an incorrect conclusion.
Should this parameter perhaps be relabeled in the documentation (or are
all the fields of the SMDI message searched)?

Also: You're probably aware (or perhaps just missed a minor doc fix after
a code change), but the example in the page you sent just shows one
parameter being passed to SMDI_MSG_RETRIEVE. It looks to me like the
<smdi_port> parameter is not optional.

I will definitely schedule some time for testing in the next week when I
can temporarily take our current production system offline. I'll let you
know how we fare. Thanks, again, for both your thorough and quick response
and the nice work you've done on Asterisk.

- Bill

--
Bill Sofko
Chief Technology Officer
Wildwood Programs