Dialog's Contact Address Problems


Background

When creating a dialog (UAC or UAS dialog), application needs to specify local address to be put in the Contact header generated by the dialog. This address normally is derived from the transport address created by the application.

This can be a complicated thing to do, because application needs to select the appropriate address based on the transport being used to contact remote peer, and it's not so easy especially when multiple transports are created, or when multiple interfaces are present in the host (multihoming).

(Note: also similarly for client registration).

So a change is being/to be made to allow the dialog to automate this process. If application specify NULL as the value of the local contact when creating a dialog, then the dialog should choose the best transport address according to the following rules.


1a. UAC

UAC SHOULD select the Contact address based on the transport to be used to send initial request to target (this can be deduced by the ";transport" param in the target URI).  For example, if initial transport is UDP, then the Contact SHOULD specify the appropriate UDP transport address.

When there are multiple transports available to reach the destination (such as multiple UDP transports, although this is not really tested/supported), then which transport to use follows the policy used by the transport manager.

Note that target can be the URI in the request URI, or the first route in the route set. Because initial route set is specified AFTER dialog is created, the Contact header generation is done when the initial request is created/sent.

Unsolved problem(s):
 - what if the remote Contact header in the 2xx response indicates different transport? Ideally the local Contact needs to be updated too, but this is quite a complicated problem, because if we change the local Contact, then remote may change its Contact too, and this can result in an endles loop.


1b. UAS

UAS MUST select the Contact address based on the value of Contact header and the Record-Route set in the incoming request.


2. Multihoming

Problem:
If application does not specify the address to be used when creating SIP transport, then transport address is calculated based on the primary IP address of the local host. Sometimes this is not the correct IP to be used by the dialog, especially when there are multiple interfaces in the host. If this "incorrect" address is specified in the Contact, then remote would not be able to send request to local host.


Workaround:
Change the behavior of determining local IP. Instead of calling gethostbyname() for local host, the local interface IP is determined by creating an UDP socket, do UDP connect() to some public host, and get the local IP address of the socket.

Although this does not fully solve the problem, hopefully it solves many problems in typical desktop systems, where an "unwanted" adapter takes precendence over the "wanted" adapter on the host/address resolution.

A fully working solution would probably involve having a table to track which interface to use based on the destination, or to query the host's routing table.