[SR-Users] SIP client TCP behaviour

[Jiri Kuthan]

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 at sip.evaristesys.com;transport=tcp
>
> My 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