Hi Cullen,
Many PSTN gateways and Softswitches always send large INVITEs for
example,
and they will always fragment. And I might add that many very
popular
NAT/routers don't support UDP fragmentation.
Hmm - I wish we had better specifics here - I will point out there
are millions of endpoints on well known residential endpoints that
are working through NATs and connected to PSTN gw and softwswiches
that are working over UDP.
If so, then how would those endpoints get any benefit from Outbound ?
What would be the value added for those deployments if those endpoints
would be changed as Outbound UDP compliant endpoints ? Multiple
registration support and new types of keepalive messages i.e. some
added reliability ?
But if those endpoints and proxies anyway have to be either upgraded
or replaced for Outbound, then why couldn't that upgrade cover TCP
support as well ? What is the ultimate benefit for using UDP instead
of TCP for those deployments ?
Uh, no - I was saying that outbound over UDP is usable in cases where
the policy is to reject messages that are too large for UDP. I agree
that limits the functionality of the communications with the UA that
registered over this UDP only network but that was that deployments
choice.
Note what I am talking about here is all about deployments using TCP
or UDP. I don't mind about if a UA has to implement both.
Please remember that the proposal that you do not agree with was
like this:
Proposal 2: Make outbound registrations over UDP flows optional for
UAs.
Outbound over UDP would still be possible and probably supported by
those UA vendors who get significant gain for it. But some UAs
targetting to other deployments could just opt to support TCP.
What is wrong with that ?
If it is the deployments choice to limit the functionality of the
communications with the UA registered, why could it not be possible
for the specific closed deployments to administratively (or
technically)
limit the deployed UAs to be such that implement UDP ? Why would you
mandate ALL the implemented UAs to support UDP for Outbound ? Those
deployments could just tell the users not to aqcuire any UAs which
only support Outbound with TCP, if the proxies (or operator policy)
does not support TCP (or does not support persistent TCP connections).
You mean a UA will open two connections, one
for UDP and another for TCP? I fail to see why on earth
anybody would do this instead of just using a single TCP connection.
I think the folks that favor these approach would use a scheme where
the UDP connection was long lived and the TCP connection was short
lived for the large messages. The advantages of this would be to get
the scaleability and reliability schemes that are easier with UDP yet
still be able to do large messages.
Please remember the Outbound draft does make such a scheme possible !
If the UA does NOT have a long lived persistent TCP connection
available, there is no way for the proxy to get the UA to open
such connection or for the proxy itself open such a TCP connection
towards the UA via the NAT when a large message arrives destined
to the UA. So if the UA does not keep the TCP connection open
all the time, it has to live with the limitation of not being
able to receive SIP requests bigger than MTU if the NAT discards
fragmented UDP packets.
P.S. Actually there is such a mechanism for that specified in Marc
Petit-Huguenin's I-D "Preventing Fragmentation for Client Initiated
Connections in the Session Initiation Protocol (SIP)" - but that
is not within the baseline Outbound spec and there is no normative
binding between those specs either.
Regards,
Erkki