id summary reporter owner description type status priority milestone component version resolution keywords cc backport_to_milestone backported 50 Explicit use of transports bennylp bennylp "= Background = The rules regarding transports are quite complicated with SIP, so because of this, it was decided during design that transports are managed automatically by the stack. This has benefit that application doesn't need to care about transport complexities, such as transport resolution, establishing/tearing-down transports, associating transport with destination, etc. With this approach, application should only need to care about the URI, and the stack will manage the transport to be used for that URI automatically. This approach works fine for typical applications. However, some unusual applications need more refined control on the transport, e.g. they want to be able to use specific transport to send outgoing messages. More over, the current transport design also has a limitation that currently only one transport type can be used per application. If application creates (for example) more than one UDP transports, the second one simply will not be used to send outgoing requests, although it '''can''' receive incoming requests. The reason why the second transport will not be selected is related to how transports are stored in the transport hash tables. Currently, transports are hashed by their transport-type and remote address. So everytime the stack needs to send SIP message to remote destination, it looks up the transport hash table using the transport-type and remote address as the hash key. Because of this, there can only be one transport registered per one transport type and one remote address (note that connection-less transport such as UDP will register 0.0.0.0:0 as its remote address) = Proposed Changes = The proposed changes to the transport framework should support the following requirements: - allow more than one transport per transport type to be registered and used. - allow application to ''bind'' a request, transaction, and possibly dialog to specific listener. - also fix ticket #42 regarding shutting down transport. A potential solution may look like this: - change the transport hash key from {type, remote-address} to {type, local-address, remote-address}. - each transport/listener will register itself '''twice''' to the hash table. First with its local address set to zero, and second with its actual local address. The first entry is used to match transport when application doesn't request for explicit binding, and the second when it does. - note that with above ''rule'', it is possible that more than one transports may occupy a single hash table entry (for example, two UDP transports will occupy the same entry because both have the same transport type, local address (zero), and remote address (zero)). Because of this, hash entry may need to be made as a list. - added API to allow binding request, transaction, or dialog with specific transport. If this binding is not established, zero address will be used to match the transport. " enhancement closed normal release-0.5.10 pjsip 0.5.9 worksforme transport