On 3/15/16 8:03 AM, ankur bansal wrote:
Hi Paul
Please explain more about what you are asserting for TLS. It looks wrong
to me, but I'm not sure I understand what you are trying to say.
I was trying to point to RFC 5923 which provides provision to reuse same
TLS connection not only for sending Requests from Caller(A) but also for
requests being generated by Callee(B) towards Caller(A).
RFC5923 was written to identify "safe" cases for connection reuse. It
spells out some. In general, reuse of connections for sending requests
in the reverse direction in any other cases is not safe. So basically,
you can do it over TLS using "alias" if a client cert was verified. You
can't use this mechanism to reuse TCP connections in other cases.
(Note that the original intent, when work on this draft was started, was
to allow reuse of plain TCP connections. But it turned out not to work.)
Since most end-user UAs don't have certs, this doesn't work for them.
For them, RFC5626 can be used, though it does't seem to be very popular.
Thanks,
Paul
@Xaled,
Apart for reasons discussed above why reuse of TCP connection not
recommended.
I think we can have another scenarios ,where its better to open new TCP
connection.See if this makes sense here :
In-dialog request(say ACK) can directly reach out to end point based on
contact address recieved in last response(say 200Ok)
OR
Following Record route ,where path(or for our interest next node where
socket to establish) is not same for in-dialog from what it was for initial
request.
Also one more point regarding Domain resolution using SRV records :
When domain gets resolved to P2 while sending in-dialog request ,that
should be assumed mainly due to P1 not responding rather than assuming DNS
load balancing at transaction level.
OR
As Paul mentioned if this is done for DNS load balancing then better to
close last TCP connection while opening new.
Regards
Ankur Bansal
On Tue, Mar 15, 2016 at 4:29 PM, xaled <xa...@web.de> wrote:
Hi,
As far as I know, the main complaint is that it can temporarily
prevent/delay honoring
the DNS configured load balancing and priorities.
So there is a consensus that transaction based DNS load balancing is more
preferable to the dialog based TCP connection reuse?
Meaning that is preferred to have initial INVITE over proxy1, call hold
reINVITE over proxy2 and BYE over proxy 3 having three TCP connections for
one dialog.
If the administrator really wants to move the traffic to a different
server he can always close existing connections.
Exactly, DNS balancing for TCP connections over dialogs makes perfect
sense. DNS balancing on transaction level make less sense as long as the
initial TCP connection is available.
If I understood the replies correctly the current state of recommendation
is that there is no requirement to reuse TCP connection inside a dialog.
Thanks,
xaled
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
