Thu Oct 11 06:49:58 2012

Asterisk developer's documentation


SIP TCP and TLS support

tcpfixes TCP implementation changes needed
Todo:
Fix TCP/TLS handling in dialplan, SRV records, transfers and much more
Todo:
Save TCP/TLS sessions in registry If someone registers a SIPS uri, this forces us to set up a TLS connection back.
Todo:
Add TCP/TLS information to function SIPPEER and SIPCHANINFO
Todo:
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
Todo:
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.
Todo:
Be prepared for one outbound and another incoming socket per pvt. This applies specially to communication with other peers (proxies).
Todo:
We need to test TCP sessions with SIP proxies and in regards to the SIP outbound specs.
Todo:
;transport=tls was deprecated in RFC3261 and should not be used at all. See section 26.2.2.
Todo:
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)
Todo:
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
Todo:
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)
Todo:
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.
When dialling unconfigured peers (with no port number) or devices in external domains NAPTR records MUST be consulted to find configured transport. If they are not found, SRV records for both TCP and UDP should be checked. If there's a record for TCP, use that. If there's no record for TCP, then use UDP as a last resort. If there's no SRV records,
Note:
this only applies if there's no outbound proxy configured for the session. If an outbound proxy is configured, these procedures might apply for locating the proxy and determining the transport to use for communication with the proxy.
Other bugs to fix ----
__set_address_from_contact(const char *fullcontact, struct sockaddr_in *sin, int tcp)

Generated on Thu Oct 11 06:49:58 2012 for Asterisk - the Open Source PBX by  doxygen 1.5.6