[asterisk-scf-dev] Asterisk SCF features I'd like to see

[Alistair Cunningham]

All,

Here are some features that I'd like to see in Asterisk SCF that aren't 
currently in Asterisk (or which could be improved). They'd make life 
much easier for those building large systems with billing. They're 
merely suggestions - feel free to tell me that I'm crazy for proposing 
these! I'm also happy to add these to the Wiki if people think they're 
good. Thoughts?

1. Call flow and logging should reflect billing realities. Consider a 
call coming in from the PSTN to a toll free number (and so is billable 
to the answering party). It's answered by a SIP handset and they talk 
for one minute. The handset then transfers the call out to a cell phone 
where the call continues for another two minutes. The inbound call needs 
to be billed for three minutes, and the outbound call for two minutes. 
The inbound call must not be considered terminated when the transfer 
happens (very important). This needs to be the same for both attended 
and blind transfers, and for calls which have been transferred multiple 
times.

2. Busy lamps need to work differently from billing. In the above 
example, the transferring SIP handset needs to be marked as idle after 
the transfer is complete, even though billing still sees an outbound 
call from it.

3. In larger installations, I think it will be common to have a very 
lightweight SIP proxy (e.g. OpenSIPS) distribute calls, registrations, 
subscribes, etc, between many Asterisk SCF machines, with RTP bypassing 
the SIP proxy. Clients behind NAT need to work correctly in this scenario.

4. The ability to inject custom SIP packets to handsets would be useful. 
I guess the ICE framework already makes this possible?

5. It would be useful to have a facility to have an ICE component 
invoked every N seconds for each call. For example, this could be used 
to update the customer's balance in an SQL database, and hang up the 
call if the prepaid balance reaches zero.

6. It would be great if all calls (including 1 and 2 party calls) were 
conferences, and channels could be added or removed at will. This could 
of course be used to implement transfers, call spy, drag-and-drop 
consoles, etc. I guess each channel connected to the call then needs to 
have a "Disconnect all channels when this channel disconnects" flag. I 
remember mentioning this to Kevin Fleming, and he said that it was under 
consideration. I don't know if this has been decided?

7. If anyone writes a voicemail application, please please use a fixed 
globally unique filename for each voicemail. Renumbering of voicemails 
makes it very hard to have features such as a "Click here to delete on 
server" link in notification emails.

-- 
Alistair Cunningham
+1 888 468 3111
+44 20 799 39 799
http://integrics.com/