7 Apr
2014
7 Apr
'14
1:29 p.m.
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=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