TCP Connection Reuse (or SIP outbound)
Jonas
I have been trying to find an answer to this question on this forum as
well as googled it all over but can't seem to find the answer to it.
My apologies if I'm just bad at searching...
I am trying to get a regular B2BUA scenario going and all the normal
stuff is working just fine but I can't seem to get the “honor what's
in the VIA header” working. As the headline eludes to, I want the
server to basically:
1. Ignore whatever the contact header says since this is over TCP so
reuse the TCP connection when sending subsequent requests back to the
client.
2. If the TCP connection has gone down for whatever reason, then
ignore the contact header once again and try to reuse the rport and
received parameter from the VIA header.
I do realize that especially no 2 may not really be correct SIP (have
to read the spec a little closer I guess) but it make sense (at least
in my particular use case). I guess they both are kind of pointing to
the sip outbound rfc (rfc5626), but I don't currently need that entire
thing.
As you probably have guess, one of my clients is behind a NAT so just
to be 100% clear about what I am trying to accomplish, I have the
following user scenario:
* Client A – behind NAT
* Server acting as a B2BUA (mobicents)
* Client B – somewhere else, not important for this discussion.
* A sends invite to the server (over tcp), stamps the Contact header
and the Via header with A's local ip and port (which is wrong in this
case).
* Server receives the invite, processes it and sends it over to B. It
will send back the 100 trying to client A and the server has filled
out rport and the received parameter correctly.
* B responds with 200, which is “b2bua:ed” by the server to side A.
The response will make it back since it either is using the same TCP
connection (as it should and clients should not terminate a tcp
connection until a final response – if I remember my sip correctly) or
will establish a new connection using the connection info in the via
header (received:rport - hence, symmetric response routing rfc thing).
* A acks and all things are good.
* Eventually, B decides to hang up, meaning that once the BYE has
reached the server, the server has to create a subsequent request on
A's dialog and send it back to A.
* Currently, this request will not make it back to A because the ACK
is being sent to the local ip and port of A.
So, my question is, is there any setting or something that I can use,
or anything I can do programatically, that will get this use case to
work?
Should probably mention that I am using mss-1.6.0.Final on-top of
jboss 5.1.0.GA
Thanks,
/Jonas
Vladimir Ralev
We've been discussing the same issues before. Turns out that the SIP
RFC section 18 already says:
When
a connection is opened by the transport layer, this index is set to
the destination IP, port and transport. When the connection is
accepted by the transport layer, this index is set to the source IP
address, port number, and transport. Note that, because the source
port is often ephemeral, but it cannot be known whether it is
ephemeral or selected through procedures in [4], connections accepted
by the transport layer will frequently not be reused.
So it is pretty much standard phones to have two separate sockets for
both directions, in fact some phones refuse to take requests on the
same socket.
No 2 - I think it already works this way for responses by spec
rfc3581, however for new requests it probably doesn't because it is
not part of the spec.
One option is to use stun on client A?
Otherwise, the code modifications needed to address you issues are not
very hard. I don't know if everyone will agree with these changes, so
I invite the users to comment. You may want to may the changes
yourself and contribute the patches if everything works and doesn't
break other cases.
Jonas
I would be more than happy to contribute a fix and if the larger
community agrees with it, then perhaps it can go into the final
product as well. Since I am unfamiliar with your code base, perhaps
you could point me in the right direction? Feel free to email me
directly.
And yes, STUN would be an option but from a pure sip perspective, you
kind of already have "stun" built in through the rport and received
tags in the via header. Also, following sip outbound, this scenario
would have been taken care of, which is why I would love to have it in
the actual container. Also, for this to really work, the STUN server
has to run on the same ip and port as the actual sip container and I
haven't found anything that would integrate with the network stack of
jain sip to dispatch STUN and SIP messages to two different protocol
stacks. Or do you guys have one?
Thanks,
/Jonas