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?
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?
Thanks,
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
On 04/07/2014 01:29 PM, Jiri Kuthan wrote:
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.
Yeah, but my Kamailio already defaults to UDP. It means I have to do extra work to override this preference. Since the next hop is opaque to the client, why should it have a say in choosing the transport used to reach it? Why should it care?
Alex Balashov writes:
Yeah, but my Kamailio already defaults to UDP. It means I have to do extra work to override this preference. Since the next hop is opaque to the client, why should it have a say in choosing the transport used to reach it? Why should it care?
it should not care except for tls.
-- juha
On 4/7/14 7:31 PM, Alex Balashov wrote:
On 04/07/2014 01:29 PM, Jiri Kuthan wrote:
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.
Yeah, but my Kamailio already defaults to UDP. It means I have to do extra work to override this preference. Since the next hop is opaque to the client, why should it have a say in choosing the transport used to reach it? Why should it care?
my point is it is entirely SIP proxy business todo anything about the incomig URI. throw away the upstream hop preferences or keep them. If it wants to have a clear result, it must basically whitelist/blacklist some URI parameters.
jiri
-
Alex Balashov -
Jiri Kuthan -
Juha Heinanen