Data-Over-Voice An experimental feature to send and receive an identification over voice channel. If a party answers, the ID is transmitted some seconds afterwards. The calling party listens 30 seconds after receiving an answer message for the ID. Add to your extension's settings file: dov_ident <id string without white spaces> dov_log /path/to/log/file dov_type pwm|pcm dov_level 0|level 'pwm' survives analog transcoding. 'pcm' is fast and will almost not be recognised. 'level' can be used to alter default signal amplitude (100..30000).
Experimental crypto feature: Support for libvootp
Fixed early audio with chan_lcr (Asterisk) If progress message is received, go into proceeding state. Send audio, if proceeding/alerting state, so RTP stream is sent in both directions. This is essential when using NAT.
Fix: Allow recording of audio for SIP/remote/GSM interfaces too
Fix: Don't forward MESSAGE_TRAFFIC to endpoint instance Thanx to Atul for catching this bug
Store caller/dialing info for calls via remote interfaces (chan_lcr)
Fix: Send tones/patterns/announcements for remote connections
Add screening of caller ID for remote (asterisk) connections
Cleanup: Make interface name be part of Port class
Maintain states for remote socket connections
Removed complete bchannel handling from chan_lcr The remote application interface does not allow any bchannel to be exported or imported. Audio traffic via socket interface is used instead. The joinremote instance became obsolete and is removed. The remote action (routing) became obsolete, use interface.conf instead. The handling of loopback device became obsolete and was removed The chan_lcr does not rely on mISDN anymore, that means: - can be used with GSM and without mISDN at all. - chan_lcr can be used as internal extension of LCR (e.g. SIP phone) (chan_lcr can be handled as any other interface) - no loopback device to be used anymore.
Adding simple bridge application to forward calls without PBX app. Call received on an interface can directly be forwarded to a given destination interface, instead of routing the call through PBX application. This way calls can be forwarded without going through route.conf. Currently only SIP and GSM destinations are supported. Also there are no tones generated, if one side provides no tones, but the other wants to receive them. The keyword "bridge <output interface>" in interface.conf is used. Without that keyword, incomming calls are handled as usual.
Additionally adding output of bchannel "ref" at some debug output.
Adding interface support for remote app (chan_lcr). chan_lcr can be handled as an interface. This way it is possible to (e.g.): - make a SIP phone become an LCR extension with all LCR features. - make conference calls. (untested) - perform parallel ringing. (ISDN phone and SIP phones can ring in parallel.) - do voice recoding. It is still also possible to link chan_lcr directly without interface (as before). Documentation/howto for that will follow.