Attila Sipos wrote:
I agree, it's not very efficient.
I think the way to avoid it would be to make
it STANDARD to always use the same TCP connection
for the duration of the call. It seems that some
implementations use a separate TCP connection
for each transaction (and some for each SIP message)
but I don't think this is necessary.
I might be wrong - maybe it is necessary (to use
so many TCP connections) but I would like to hear
someone explain why.
You can't use the same TCP connection for the entire session (i.e.
multiple requests within the session). At least, the specification
cannot mandate it. Consider, for instance the following scenarios:
1) A UAC used a pre-loaded Route with its proxy's URI when
it send out the first dialog-establishing INVITE. It may
not want to send subsequent requests through the same proxy,
and in fact, may now enter peer-to-peer mode and contact
its peer directly. Clearly, the TCP socket it opened up
with the proxy is no longer valid.
2) A UAC send out an INVITE through a default outbound proxy
which decided NOT to R-R. However, some further downstream
proxies decide to R-R. Thus, subsequent requests should
go to the downstream proxies, not the default outbound proxy.
Again, the TCP socket opened with the default outbound proxy
is no longer valid.
Having said that, certain optimizations are possible. For instance,
if a UAC knows the FQDN of its peer (not the AoR, but the routable
FQDN), it can open a TCP socket and always use that for subsequent
communications. Or, if a UAC ALWAYS sends requests to a default
outbound proxy regardless of the URI, it could probably have a
"nailed up" TCP connection with that proxy.
And another question is - how should forking be
handled?
I think that all the forks should use the same
TCP socket as used by the original INVITE.
Otherwise this gets very complicated.
If you mean responses to forked requests (or for that matter, any
request sent over TCP) should come over the same TCP socket, yes. But
it is conceivable to design and architect your software in such a manner
that it really does not matter if the UAS opened another socket for
sending a response -- it is not an optimal way of doing it, no doubt.
Regards,
- vijay
--
Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566 Voice: +1 630 224 0216
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
