Currently only the first audiohook of a specific source found will be moved. We should add the capability to move multiple audiohooks from a single source as well.
Have multiple return codes based on the MACRO_RESULT
Make constants so that caller and frame can be more expressive than just '1' and '0'
Have multiple return codes based on the MACRO_RESULT
Make constants so that caller and frame can be more expressive than just '1' and '0'
Note that in future, we need to move to a model where we can differentiate further - e.g. between en_US & en_UK
Support config reloading.
Fix native bridging.
Better support of forking
VIA branch tag transaction checking
Transaction support
need a better return code here
need a better return code here
need a better return code here
Check video RTP keepalives
Currently, when the state of a device changes, the device state provider calls one of the functions defined here to queue an object to say that the state of a device has changed. However, this does not include the new state. Another thread processes these device state change objects and calls the device state provider's callback to figure out what the new state is. It would make a lot more sense for the new state to be included in the original function call that says the state of a device has changed. However, it will take a lot of work to change this.
Implement a caching mechanism for multile enum lookups
The service type selection needs to be redone.
Delete the entry from AstDB when set to nothing like Set(DEVICE_STATE(Custom:lamp1)=)
Move app_getcpeid into this module
Create a core layer so that app_voicemail does not require res_adsi to load
Support responding to a meeting invite
Support writing attendees
If you unload this module, chan_gtalk/jingle will be dead. How do we handle that?
Dialplan applications need RETURN variable, like JABBERSENDSTATUS
Make informational security events optional
Escape quotes in string payload IE contents
XXX If we have sip_cfg.srvlookup on, then look for NAPTR/SRV, otherwise, just look for A records
XXX If we have sip_cfg.srvlookup on, then look for NAPTR/SRV, otherwise, just look for A records
XXX If we have sip_cfg.srvlookup on, then look for NAPTR/SRV, otherwise, just look for A records
Fix TCP/TLS handling in dialplan, SRV records, transfers and much more
Save TCP/TLS sessions in registry If someone registers a SIPS uri, this forces us to set up a TLS connection back.
Add TCP/TLS information to function SIPPEER and SIPCHANINFO
If tcpenable=yes, we must open a TCP socket on the same address as the IP for UDP. The tcpbindaddr config option should only be used to open ADDITIONAL ports So we should propably go back to bindaddr= the default address to bind to. If tcpenable=yes, then bind this to both udp and TCP if tlsenable=yes, open TLS port (provided we also have cert) tcpbindaddr = extra address for additional TCP connections tlsbindaddr = extra address for additional TCP/TLS connections udpbindaddr = extra address for additional UDP connections These three options should take multiple IP/port pairs Note: Since opening additional listen sockets is a *new* feature we do not have today the XXXbindaddr options needs to be disabled until we have support for it
We need to test TCP sessions with SIP proxies and in regards to the SIP outbound specs.
;transport=tls was deprecated in RFC3261 and should not be used at all. See section 26.2.2.
Since we have had multidomain support in Asterisk for quite a while, we need to support multiple domains in our TLS implementation, meaning one socket and one cert per domain
Selection of transport for a request needs to be done after we've parsed all route headers, also considering outbound proxy options. First request: Outboundproxy, routes, (reg contact or URI. If URI doesn't have port: DNS naptr, srv, AAA) Intermediate requests: Outboundproxy(only when forced), routes, contact/uri DNS naptr support is crucial. A SIP uri might lead to a TLS connection. Also note that due to outbound proxy settings, a SIPS uri might have to be sent on UDP (not to recommend though)
Default transports are set to UDP, which cause the wrong behaviour when contacting remote devices directly from the dialplan. UDP is only a fallback if no other method works, in order to be compatible with RFC2543 (SIP/1.0) devices. For transactions that exceed the MTU (like INIVTE with video, audio and RTT) TCP should be preferred.
re-evaluate the transport= setting in sip.conf. This is right now not well thought of. If a device in sip.conf contacts us via TCP, we should not switch transport, even if udp is the configured first transport.
Be prepared for one outbound and another incoming socket per pvt. This applies specially to communication with other peers (proxies).
If the message is smaller than the given Content-length, the request should get a 400 Bad request message. If it's a response, it should be dropped. (RFC 3261, Section 18.3)
Get socket for dialog, prepare if needed, and return file handle
Check this... This might be wrong, depending on the proxy configuration If proxy is in "force" mode its correct.
Check this... This might be wrong, depending on the proxy configuration If proxy is in "force" mode its correct.
XXX This should be altered in the future not to use a FILE pointer
XXX If there's no Content-Length or if the content-length and what we receive is not the same - we should generate an error
XXX If there's no Content-Length or if the content-length and what we receive is not the same - we should generate an error
Fix the transfer() dialplan function so that a transfer may fail
In theory, we should hang around and wait for a reply, before returning to the dial plan here. Don't know really how that would affect the transfer() app or the pbx, but, well, to make this useful we should have a STATUS code on transfer().
In theory, we should hang around and wait for a reply, before returning to the dial plan here. Don't know really how that would affect the transfer() app or the pbx, but, well, to make this useful we should have a STATUS code on transfer().