Better support of forking
VIA branch tag transaction checking
Transaction support
need a better return code here
need a better return code here
Implement a caching mechanism for multile enum lookups
The service type selection needs to be redone.
Fix this XXX This must be all wrong XXXX
Leaking anything allocated by reload_config() ...
XXX we would like to wait on both!
XXX Play a message XXX
XXX here too we interpret a missing as a name-only URI, whereas the RFC says this is a domain-only uri.
OEJ Remove this - there's never RTP in a REGISTER dialog...
Move app_getcpeid into this module
Create a core layer so that app_voicemail does not require res_adsi to load
If you unload this module, chan_gtalk/jingle will be dead. How do we handle that?
Dialplan applications need RETURN variable, like JABBERSENDSTATUS
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.
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().