RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound

[<Erkki.Koivusalo at nokia.com>]

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip