[SIPForum-techwg] SIPConnect 1.1 - Microsoft proposalandadditional requirements- TCP
Francois Audet
audet at nortel.com
Fri May 16 11:57:22 EDT 2008
Again, our goal is not to document existing practice. There is no point
in doing this.
There are a number of well-known reasons why we should be encouraging people to use
TCP.
TCP cannot be a MAY.
> -----Original Message-----
> From: Kaushik V Shah [mailto:kaushik at ncoretech.com]
> Sent: Thursday, May 15, 2008 23:03
> To: Audet, Francois (SC100:3055)
> Cc: Peter Dunkley; Russell Bennett; techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] SIPConnect 1.1 - Microsoft
> proposalandadditional requirements- TCP
>
> I understand the point on compliance, but I tend to agree
> with following (reproduced from Jamie's mail):
>
> > ...I hope we can get to closure on CODECS and Transports pretty
> > quickly....I agree with Janne -- IMHO, UDP and G711 (and probably
> > RFC2833) should be MUST. In the real world, this is what's
> > happening. Everything else should be a MAY -- and let the...
>
> My apologies if this has been put out of context. But I did
> not think so.
>
> Regards,
> Kaushik
>
> Francois Audet wrote:
> > TCP can not be optional. Period. That would violate RFC 3261.
> >
> >
> >> -----Original Message-----
> >> From: Kaushik V Shah [mailto:kaushik at ncoretech.com]
> >> Sent: Thursday, May 15, 2008 04:13
> >> To: Peter Dunkley
> >> Cc: Audet, Francois (SC100:3055); Russell Bennett;
> >> techwg at sipforum.org
> >> Subject: Re: [SIPForum-techwg] SIPConnect 1.1 - Microsoft
> >> proposalandadditional requirements- TCP
> >>
> >> I agree with Peter.
> >>
> >> And would like to ask this group:
> >>
> >> Can the base specification be such that it is more inclusive than
> >> otherwise?
> >> And will SIPConnect 1.1 be better off by making TCP
> optional in the
> >> base profile (even though SIP3261 mandates use of both)?
> >>
> >> This will make large existing base eligible for SIPConnect
> >> 1.1 certification, if one gets planned / offered by sipforum.
> >>
> >> Regards,
> >> Kaushik
> >>
> >> Peter Dunkley wrote:
> >>
> >>> 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 <mailto: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 <mailto:joanne at avaya.com>
> >>>>
> >>>> ----- Original Message -----
> >>>>
> >>>> *From:* Russell Bennett
> >>>> <mailto:Russell.Bennett at microsoft.com>
> >>>>
> >>>> *To:* techwg at sipforum.org
> >>>> <mailto: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
> >>>> <mailto:Alice at x.com> is in a call with
> >>>>
> >> Bob at y.com
> >>
> >>>> <mailto:Bob at y.com>, she is unlikely
> to want to
> >>>> transfer Bob to Carol at y.com
> >>>>
> >> <mailto: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
> >>>>
> >>>>
> >>> --
> >>> *Peter Dunkley*
> >>>
> >>>
> >>> *Email:* peter at dunkley.me.uk <mailto:peter at dunkley.me.uk>
> >>> *http://www.linkedin.com/in/pdunkley*
> >>> *My Website <http://www.dunkley.me.uk/>*
> >>>
> >>> See who we know in common <http://www.linkedin.com/e/wwk/4086755/>
> >>> Want a signature like this?
> <http://www.linkedin.com/e/sig/4086755/>
> >>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >> -
> >>
> >>> --
> >>>
> >>> _______________________________________________
> >>> techwg mailing list
> >>> Send mail to: techwg at sipforum.org
> >>> Unsubscribe or edit options at:
> >>> http://sipforum.org/mailman/listinfo/techwg
> >>>
> >>>
> >> The information contained in this electronic message and any
> >> attachments to this message are intended for the exclusive
> use of the
> >> addressee(s) and may contain proprietary, confidential or
> privileged
> >> information. If you are not the intended recipient, you should not
> >> disseminate, distribute or copy this e-mail. Please notify
> the sender
> >> immediately and destroy all copies of this message and any
> >> attachments contained in it.
> >>
> >> Contact your Administrator for further information.
> >>
> >>
> >>
> >
> >
>
>
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive
> use of the addressee(s) and may contain proprietary,
> confidential or privileged information. If you are not the
> intended recipient, you should not disseminate, distribute or
> copy this e-mail. Please notify the sender immediately and
> destroy all copies of this message and any attachments
> contained in it.
>
> Contact your Administrator for further information.
>
>
More information about the techwg
mailing list