For historic context, this was the rationale for the asymmetry:
----- on 9 Jan 2008---
We'd like to propose a change to simplify the setOutboundInterface (http://www.289eg.org/cb/proj/tracker/itemDetails.do?navigation=true&task_id=1028) syntax and semantics.
The idea is to introduce two methods :
void setOutboundInterface(java.net.InetSocketAddress address)
void setOutboundInterface(java.net.InetAddress address)
Instead of existing:
void setOutboundInterface(SipURI uri)
The motivation of this change is to allow the developers to easily influence the source port number and IP address chosen by the container when originating requests for SipSession/Proxy/ProxyBranch without interfering with RFC-defined transport selection rules.
Kristoffer and I spent some time discussing various use cases around the existing 1.1 API (i.e. uri is supplied instead of just the address or address/port combination).
While trying to write all the corner/error cases out, I realized that the RFC-dictated transport selection rules were rather difficult to work around and a simpler mechanism would be preferable.
Please let us know what you think.
Jarek & Mihir
----- on 1 May 2008, in response to a question on consistency---
The short answer is no.
The idea behind using URI in the ctx attr is that a container implementation could indicate which interfaces are SIPS capable, or possibly limited to a specific transport ('transport=tcp'). The setOutboundInterface takes and InetAddr because we don't want it to interfere with SIP transport type selection rules.