[asterisk-dev] SMDI on 1.6.0-beta5

[Bill Sofko]

Thanks to Russell for his work in enhancing the SMDI module in the
forthcoming Asterisk 1.6.0. The timing is great as we've been running a
home-grown SMDI module on 1.2.x for a couple of years now, would like to
move to 1.6.0, but didn't want to expend the effort in porting or
maintaining our own module if there was official support for SMDI.

Our efforts in migrating just started this week and I've been reading the
1.6.0/SVN source and looking specifically at Issue #0009260. The reporter
of that issue correctly states that for SMDI to work properly there has to
be a mapping between an SMDI message and a specific channel. That issue is
reported as being "fixed" and the status is "closed", but my read of the
current source suggests that this may still be an issue. That is, unless
I'm mistaken (and I'd be happy to be so), the SMDI code is still dependent
on the assumption that SMDI messages will be queued totally in step with
channels as they get opened by incoming calls. Is my understanding of this
correct? If it is, then it is possible for SMDI messages to be delivered
to the wrong channels, which will cause problems.

Additionally, even if my understanding is wrong, I think there's a
shortcoming in the implementation along the lines that the reporter of
#0009260 suggested with regard to needing a message desk terminal to Zap
channel mapping. In the submitted patch (not applied -- see notes) the
developer assumed that the MD terminal number would match the Zap channel
(worked in their use case). This is not necessarily going to be the case
and, in fact, in our production situation, it definitely is not. As such,
I would suggest that zapata.conf be extended to include such a mapping on
a per channel basis (for example, smditerm=0005).

The patch additionally (I think) had a shortcoming in only handling
situations in chan_zap.c where there was a forwarding station number
(types "A", "B", and "N" would include this "field"). In a type "D"
message (direct call) there would not be a forwarding station number, but
the channel should still have the associated SMDI message (again, we
depend on this).

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.

Thanks for your consideration of my thoughts.

- Will

--
Will Sofko
Chief Technology Officer
Wildwood Programs