On 4/7/14 5:53 PM, Alex Balashov wrote:
Hello,
I don't know a lot about SIP with TCP, so I thought I'd ask for some opinions here. I've been testing Kamailio with TCP against the Android SIP client (4.4.2) and have found, to my annoyance, that it sends a RURI with a transport attribute in its INVITEs:
INVITE sip:14045551212@sip.evaristesys.com;transport=tcpMy upstream gateways are all UDP, so this causes Kamailio to attempt to contact them all via TCP (and fail).
I know how to bend the transport with Kamailio, and I can strip this attribute. My question is more methodological: is this "correct" for a client to do?
Think of it as a hop-by-hop attribute expressing its next-hop (i.e. proxy) transport preference for outbound request, K is free to rewrite it to its liking.
In my opinion, the answer is no. The client should not be so presumptuous. It should specify the transport in its Contact, to indicate how it wants to be reached, and leave other decisions about transport to the UAS. But is there something I am perhaps missing?
You are right for inbound.
If a "reasonably behaving" application has choice of transport, I would be perfectly fine with indicating it explicitely both in outbound request-URIs and Contacts that "attract" inbound requests.
-jiri