[SIPForum-techwg] SIPConnect 1.1 - Microsoft proposalandadditional requirements- TCP
Francois Audet
audet at nortel.com
Thu May 15 00:38:14 EDT 2008
The problem with fragmentation is that many NATs do not buffer and
re-assemble fragmented packets. And by ³many², I mean ³many of the ones
found on the market ³ for large corporate NATs. Without getting into
details, it has to do with DOS attacks, and it is unlikely that the
situation will change. The problem arises if the packet fragments arrive
out-of-order. The NAT is incapable of mapping the out-of-order packet to a
specific UDP port binding because the port number is in the header (which is
in the packet that has not arrived yet). So it¹s not a packet loss issue at
all. You can easily get into a situation where you can¹t receive any calls
at all for example (or make them).
So, what should we do?
I think pragmatically, we should mandate what RFC 3261 says, which is all
equipment must support both UDP and TCP.
The service provider should be allowed to use whatever it pleases as the
default. We should RECOMMEND TCP for sure.
We also should mandate that equipment should have a configuration setting
that allows them to use either transport when sending dialog-initiating
requests in the absence of an indication in the protocol on which one to
use. Mid-dialog request should re-use the same transport f course. And
finally, when using sending a request to a URI, you need to respect the
transport= parameter regardless.
On May14 2008 18:36 , "Peter Dunkley" <peter at dunkley.me.uk> wrote:
> Granted, supporting TCP in RFC 3261 is mandatory - but so is UDP, and so is
> receipt of fragmented UDP. It is just the sending of fragmented UDP that is
> not permitted.
>
> I take your point that only supporting UDP may (or will) lead to problems.
> However, exactly the same is true of only supporting TCP.
>
> I stand by my point that RECOMMENDing the use of TCP will actually have little
> practical effect. If UDP is allowed, and using UDP by default (even if that
> implementation supports the sending and/or receiving of TCP as well) suits or
> simplifies a particular implementation this is what people are going to do -
> whether it is RECOMMENDED in the recommendation that they use TCP or not.
>
> It seems entirely valid to me that a UDP only device cannot be SIPconnect
> certified, but this is quite different from preventing such a device from
> connecting to SIPconnect compliant devices or networks - which could be a side
> effect of making UDP optional as described in the proposal document.
>
> Surely you MUST support receiving calls over TCP and UDP (including fragmented
> datagrams), even if the SIPconnect recommendation only allows you make calls
> using TCP.
>
> On a purely academic point I have never really understood why fragmented UDP
> datagrams are (in the real world) a problem anyway. Sure if you have
> fragmented UDP you are more likely to have problems because you lose part of a
> message, but SIP has timers for retransmitting messages over unreliable
> transports. If your network connection is poor enough that you are so
> consistently losing fragments that things stop working you will surely be
> having significant problems with your RTP media streams which are also
> (usually) transmitted using UDP. The reduction in call quality from lost
> media packets wouldn't (in a network with enough packet loss for fragmentation
> of SIP to be a problem) be a trivial matter, it would cause a lot of call
> slam-downs, and in a PSTN replacement/alternative system would have people
> running back to the PSTN.
>
> Regards,
>
> Peter
>
> Francois Audet wrote:
>>
>> Yeah, what I was alluding to is the following:
>>
>> *
>> * Basically, RFC 3261 says that you should switch to TCP "on the fly"
>> whenever you send a request or a response that is too big. Practically
>> speaking, this is extremelly difficult to implement and I have never heard of
>> any implementation actually doing this. Furthermore, this concept of
>> "upgrading on the fly to TCP from TCP" whenever a packet is too big plainly
>> does not work in many scenarios. For example, it will not work when there is
>> a NAT or firewall because bindings and pinholes are assigned on the 5-tuple
>> not the 3-tuple (i.e., creating a binding or opening a pinhole with UDP does
>> NOT create the corresponding binding or open the corresponding pinhole for
>> TCP).
>> *
>> *
>> * What I am therefore saying is that if there is any chance that messages
>> MIGHT be bigger than the maximum, then you MUST use TCP for all SIP
>> signalling, as opposed to attempt this "on the fly upgrading" that basically
>> doesn't work.
>> *
>>
>> Another note on "simple devices" that don't send big messages... While this
>> may be true, you never know what the far end will send you. The messages from
>> the far end may be big. And in fact (this is a trunking specification), they
>> often are.
>>
>>
>>
>> If you go to a few scenarios in your head, you'll find out that UDP will
>> break in many scenarios.
>>
>>
>>
>> Finally, remember supporting TCP is mandatory in RFC 3261...
>>
>>
>>>
>>>
>>>
>>> From: Peter Dunkley [mailto:peter at dunkley.me.uk]
>>> Sent: Wednesday, May 14, 2008 16:03
>>> To: Audet, Francois (SC100:3055)
>>> Cc: Zweig, Greg; Joanne McMillen; Russell Bennett; techwg at sipforum.org
>>> Subject: Re: [SIPForum-techwg] SIPConnect 1.1 - Microsoft
>>> proposalandadditional requirements- TCP
>>>
>>>
>>> I am not sure there is a need to specify that TCP MUST be used when packets
>>> will fragment as this is already covered in RFC 3261.
>>>
>>> Section 18.1.1 Sending Requests clearly indicates that if a request is
>>> within 200 bytes of the path MTU, or if the request is larger than 1300
>>> bytes and the path MTU is unknown, the request MUST be sent over a
>>> congestion controlled transport protocol (in this case TCP).
>>>
>>> I do not favour removing the option of using UDP. For simple devices that
>>> will not generate large messages there is some advantage in allowing UDP to
>>> be used and no apparent benefit from using TCP. From a purely engineering
>>> point of view, an operating system and TCP/IP stack is still not guaranteed
>>> in a (simple) embedded device, and in the absence of these it is almost
>>> trivial to implement (non-fragmenting) UDP/IP, but certainly not so for
>>> TCP/IP. From a practical point of view there are still a number of
>>> implementations that only support UDP (though this is getting less common),
>>> which can be seen in the SIPit implementation survey results.
>>>
>>> I am not sure that RECOMMENDing TCP in all cases will have an effect. If UDP
>>> is allowed there will be no shortage of implementations that use it in
>>> preference if that suits their implementation and usage scenario -
>>> regardless of what is recommended.
>>>
>>> The RFC also indicates that while you should not fragment, you must support
>>> receipt of fragmented messages. However, is this something that SIPconnect
>>> could help with, by specifically making proof of compliance to section
>>> 18.1.1 mandatory. This would ensure that a SIPconnect compliant device
>>> would never use UDP inappropriately (but still cope with devices that do).
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>> Francois Audet wrote:
>>>>
>>>> Right.
>>>>
>>>>
>>>>
>>>> That's why I was thinking that one option is to describe WHEN you MUST use
>>>> TCP. Those would include:
>>>>
>>>> *
>>>> * When you need to secure the signaling chanel with TLS (obviously)
>>>> *
>>>> *
>>>> * When it is possible that any packets will be so big they will fragment
>>>> and cause problems
>>>> *
>>>>
>>>> And also, RECOMMEND to use TCP otherwise.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: Zweig, Greg [mailto:gzweig at sonusnet.com]
>>>>> Sent: Wednesday, May 14, 2008 14:58
>>>>> To: Audet, Francois (SC100:3055); Joanne McMillen; Russell Bennett;
>>>>> techwg at sipforum.org
>>>>> Subject: RE: [SIPForum-techwg] SIPConnect 1.1 - Microsoft
>>>>> proposalandadditional requirements- TCP
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I would encourage the group to look at the issue beyond the technical
>>>>> merits. In my mind SIPConnect is all about encouraging interoperability;
>>>>> we all benefit from the rapid adoption of this paradigm. Based on my
>>>>> experience, I would suspect that there is a significant installed base of
>>>>> IP-PBXs that can¹t support a SIP over TCP solution without a significant
>>>>> software upgrade and potentially large hardware investments. I¹m also
>>>>> concerned that some vendors will delay adoption when they are forced to
>>>>> upgrade portfolio elements to make their solutions compliant. Worse, they
>>>>> could burden solutions with convoluted translation devices. Making a
>>>>> change like this can have significant ³ripple² effects that we should not
>>>>> discount. It would seem that Microsoft has made a wise strategic decision
>>>>> with their architecture but I think we have to recognize that this is a
>>>>> new design and we could be unintentionally burdening businesses that took
>>>>> our advice and moved to a VoIP solution so they would be ³ready² for the
>>>>> future. I don¹t want to stop time but I think we¹ll more likely need a
>>>>> dual solution that accommodates either in some way. Perhaps It might mean
>>>>> two levels of compliance (like b and g in wireless)? I¹m not going to
>>>>> suggest how but I think the goal needs to be considered.
>>>>>
>>>>>
>>>>> I would also like to understand Microsoft¹s plans for RT Codec support?
>>>>> I¹m a big fan of wideband codecs such as G722.1 and RT so I believe such
>>>>> solutions should be included but it seems that more common narrowband
>>>>> codecs like G.729 need to be there. Most of the IP phones older than 14-18
>>>>> months can¹t support G.722.1 and most are already licensed for 729.
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Greg Zweig
>>>>>
>>>>> Sonus Networks. Inc
>>>>>
>>>>> (978) 614-8027
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
>>>>> Behalf Of Francois Audet
>>>>> Sent: Wednesday, May 14, 2008 5:04 PM
>>>>> To: Joanne McMillen; Russell Bennett; techwg at sipforum.org
>>>>> Subject: Re: [SIPForum-techwg] SIPconnect 1.1 - Microsoft
>>>>> proposalandadditional requirements
>>>>>
>>>>>
>>>>>
>>>>> Right. We talked about defining draft-ietf-sip-outbound to work only with
>>>>> TCP, but people didn't want to do this.
>>>>>
>>>>>
>>>>> I don't expect a formal deprecation of UDP until there is a SIP 3.0, which
>>>>> there are no plans for today.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Joanne McMillen [mailto:joanne at avaya.com]
>>>>>> Sent: Wednesday, May 14, 2008 14:00
>>>>>> To: Audet, Francois (SC100:3055); Russell Bennett; techwg at sipforum.org
>>>>>> Subject: Re: [SIPForum-techwg] SIPconnect 1.1 - Microsoft proposal
>>>>>> andadditional requirements
>>>>>>
>>>>>>
>>>>>>
>>>>>> I agree with the proposal as well for mandating TCP in the Forum - just
>>>>>> wanted to know if anyone had the answer to
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> the IETF question since we will indeed be "a bit non-compliant" with 3261
>>>>>> when making the mandate...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Francois Audet <mailto:audet at nortel.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> To: Joanne McMillen <mailto:joanne at avaya.com> ; Russell Bennett
>>>>>>> <mailto:Russell.Bennett at microsoft.com> ; techwg at sipforum.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sent: Wednesday, May 14, 2008 1:47 PM
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Subject: RE: [SIPForum-techwg] SIPconnect 1.1 - Microsoft proposal
>>>>>>> andadditional requirements
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I dont' think that it will be deprecated anytime soon.
>>>>>>>
>>>>>>>
>>>>>>> That being said, there are things like TLS that require TCP, and things
>>>>>>> like draft-ietf-sip-outbound (for high availability and NAT traversal)
>>>>>>> that work a lot better with TCP than with UDP.
>>>>>>>
>>>>>>>
>>>>>>> So I'm thinking that a "slow migration" is more likely.
>>>>>>>
>>>>>>>
>>>>>>> I don't think it would be out of the question for SIP Forum to mandate
>>>>>>> use of TCP if we wanted to. Or recommend it. Or explain that it must be
>>>>>>> use for certain scenarios, etc. We have many options.
>>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
>>>> Behalf Of Joanne McMillen
>>>> Sent: Wednesday, May 14, 2008 13:36
>>>> To: Russell Bennett; techwg at sipforum.org
>>>> Subject: Re: [SIPForum-techwg] SIPconnect 1.1 - Microsoft proposal
>>>> andadditional requirements
>>>>
>>>>
>>>>
>>>> One quick question regarding number two:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Wasn't it the case that IETF was going to deprecate UDP in 3261? What
>>>> happened to that?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This debate has been going on for years - perhaps the Forum could influence
>>>> getting resolution there in IETF?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --------------------------------------
>>>> Joanne McMillen
>>>> Systems Engineer
>>>> Converged Communications Division
>>>> Avaya Inc.
>>>> Phone/Fax: +1.303.538.4060
>>>> Email: joanne at avaya.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>
>>>>
>>>>
>>>>
>>>> From: Russell Bennett <mailto:Russell.Bennett at microsoft.com>
>>>>
>>>>
>>>>
>>>>
>>>> To: techwg at sipforum.org
>>>>
>>>>
>>>>
>>>>
>>>> Sent: Wednesday, May 14, 2008 12:58 PM
>>>>
>>>>
>>>>
>>>>
>>>> Subject: [SIPForum-techwg] SIPconnect 1.1 - Microsoft proposal
>>>> andadditional requirements
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> All,
>>>>
>>>>
>>>> The list has been very quiet since we submitted our proposal, so let me
>>>> start the discussion.
>>>>
>>>>
>>>> First of all, here some clarification / explanation of the origin of the
>>>> document.
>>>>
>>>>
>>>> This *is* (as many of you will probably suspect) a *largely* neutralized
>>>> version of a spec that we developed for our own purposes. We have been
>>>> working with Service Providers to come up with an interface definition that
>>>> they and we can support for SIP Trunking. We have reviewed that document
>>>> with a number of Service Providers and most (but not all) have found no
>>>> issue with our approach.
>>>>
>>>>
>>>> I was asked by Rich Shockey and Scott Hoffpauir if we would be willing to
>>>> submit that document to the TWG to ³prime the pump² for SC1.1. Our initial
>>>> goal is to ease deployment of SIP Trunk solutions for everyone so we were
>>>> happy to do this. The sections of the document that are Microsoft
>>>> specific will be altered as a natural outcome of this process.
>>>>
>>>>
>>>> I have received private feedback internally and externally that the
>>>> document is incomplete: of this I have no doubt. We, like everyone else,
>>>> are limited to a view of the world from our own perspective this is where
>>>> collaboration among a group of well informed peers will rapidly drive a
>>>> clean and easy to deploy standard.
>>>>
>>>>
>>>> I strongly suggest that we don¹t try to boil the ocean with myriad issues
>>>> and requirements, albeit valid, that will go much beyond basic ³call setup
>>>> and teardown². Our objective should be to develop a standard that makes
>>>> it easy for vendors and service providers to adopt SC1.1. We can ³layer
>>>> on² additional requirements in later versions of the standard that can be
>>>> selectively adopted as required.
>>>>
>>>>
>>>> That being said, let me comment on particular requirements that have been
>>>> brought to my attention:
>>>>
>>>>
>>>> 1) Definition of network elements:
>>>>
>>>>
>>>>
>>>> I have anonimized the elements that interface between two networks as
>>>> ³Enterprise Proxy² and ³Service Provider Proxy². These are logical
>>>> elements that are capable of handling signaling and media. There is no
>>>> attempt to suggest or limit any capabilities of these elements beyond
>>>> establishing voice sessions between two networks. The bundling of
>>>> additional value in these elements, including security features, is IMHO
>>>> outside the scope of this effort. Enterprises, Vendors and Service
>>>> Providers are at liberty to define their own features and requirements that
>>>> go beyond the transmission of voice traffic.
>>>>
>>>>
>>>> 2) SIP Transport:
>>>>
>>>>
>>>>
>>>> I proposed UDP=MAY, TCP=MUST, TLS=MAY. While this does not align perfectly
>>>> with 3261, there is a strong argument for TCP as the base transport based
>>>> on the fact that SIP messages tend to exceed 1500 bytes these days. 3261
>>>> says that a UA offering UDP must also offer TCP, but not vice versa:
>>>>
>>>>
>>>> Making TCP mandatory for the UA is a substantial change from RFC 2543. It
>>>> has arisen out of the need to handle larger messages, which MUST use TCP,
>>>> as discussed below. Thus, even if an element never sends large messages,
>>>> it may receive one and needs to be able to handle them.
>>>>
>>>>
>>>> Many current SPs deviate from this, offering only UDP on the grounds that
>>>> TCP is too resource intensive. I believe that this can be resolved with
>>>> TCP connection reuse. Furthermore, ³service provider proxies² in
>>>> deployment today are capable of B2B¹ing TCP to UDP so this issue can be
>>>> overcome via a choice that they are well able to implement.
>>>>
>>>>
>>>> IMHO, it is too early to make TLS (or SRTP for that matter) a MUST,
>>>> although this is a desirable longer term goal. There are many issues to be
>>>> worked out with respect to this, and we can layer communications security
>>>> requirements onto the standard later. For now, most (all?) SPs offer SIP
>>>> Trunking on a closed data connection with a VPN, so resolving that issue is
>>>> not urgent.
>>>>
>>>>
>>>> 3) 911/emergency calling, including provision of location information
>>>>
>>>>
>>>>
>>>> This is a regulatory requirement in some jurisdictions but not others,
>>>> therefore it should be optional and arguably, covered in a later spec. The
>>>> advent of mobile IP communications has made this a difficult requirement to
>>>> resolve Œautomagically¹. There are vendors who attempt to resolve it but
>>>> there is no clear standard. At Microsoft, we are working on this, but have
>>>> nothing to contribute to a standard at this time.
>>>>
>>>>
>>>> 4) FAX
>>>>
>>>>
>>>>
>>>> This is an area that c/should be added to the discussion.
>>>>
>>>>
>>>> 5) List of codecs to be offered
>>>>
>>>>
>>>>
>>>> Based on discussions with SPs, we understand that G.711 is not universally
>>>> acceptable due to bandwidth utilization concerns and that G.722.1 (for
>>>> example) would be a better choice. I suggest that we limit the mandatory
>>>> set of codecs to the minimum set of universally acceptable codecs and not
>>>> mandate codecs that have onerous IP/royalty conditions attached to them.
>>>>
>>>>
>>>> 6) Privacy
>>>>
>>>>
>>>>
>>>> This is a hot topic and various RFCs address this. We take a very strict
>>>> view of privacy that is implemented within our infrastructure, regardless
>>>> of what is sent in the SIP message. However, what is under consideration
>>>> in this initiative is the definition of private SIP/RTP connection between
>>>> a SP and an Enterprise (i.e. the sessions do not traverse untrusted
>>>> intermediary network elements or public networks). Therefore, I suggest
>>>> that we defer privacy issues to a later version of the spec and assume for
>>>> now that privacy is addressed in the trust relationship between those two
>>>> entities.
>>>>
>>>>
>>>> 7) Other features, e.g. Transfer, Call History, etc.
>>>>
>>>>
>>>>
>>>> These are Œnice-to-haves¹ that can be dealt with later in order to speed
>>>> completion of this initiative. I suspect that support of these mechanisms
>>>> is spotty and this will be an adoption blocker in the short term. Per
>>>> above, we should address the uber issue of SC1.0 non-adoption by making
>>>> SC1.1 easy to adopt. For example: it is not clear to me that Transfer is
>>>> mandatory requirement in a SIP Trunk: this function should be handled by
>>>> elements behind the Enterprise and Service Provider Proxies. If
>>>> Alice at x.com is in a call with Bob at y.com, she is unlikely to want to
>>>> transfer Bob to Carol at y.com.
>>>>
>>>>
>>>> Russell
>>>>
>>>>
>>>> ---------------------------------------------------
>>>>
>>>> Russell Bennett
>>>>
>>>> Partner Program Manager
>>>>
>>>> Office Communications Group
>>>>
>>>>
>>>> Microsoft Corporation
>>>>
>>>> One Microsoft Way
>>>>
>>>> Redmond, WA 98052-6399
>>>>
>>>>
>>>> mailto: russben at microsoft.com <mailto:russben at microsoft.com>
>>>>
>>>> sip: russben at microsoft.com <mailto:russben at microsoft.com>
>>>>
>>>> tel: +1 (425) 706-3622
>>>>
>>>> http://www.microsoft.com/uc/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> techwg mailing list
>>>> Send mail to: techwg at sipforum.org
>>>> Unsubscribe or edit options at:
>>>> http://sipforum.org/mailman/listinfo/techwg
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> techwg mailing list
>>>> Send mail to: techwg at sipforum.org
>>>> Unsubscribe or edit options at:
>>>> http://sipforum.org/mailman/listinfo/techwg
>>>>
>>>>
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20080514/f8e30e78/attachment-0001.html
More information about the techwg
mailing list