[SIPForum-techwg] Focus on simple PSTN?

Thu May 15 12:56:06 EDT 2008

I actually think SIPConnect should describe a basic level of interoperability between two SIP systems, aka SIP Trunking. This should be so well defined that it should work between two untested systems out of the box, and this should happen soon. I think the only way to achieve this objective is to look at current best practice and define a new specification that will work for current implementations as they are or with limited modifications. 

I agree with you that this is very limiting. And that is why I think we should have two levels in the spec a very basic and one forward looking utilizing all what SIP was once intended to do. No one will be happier then me when we have IP the way for both fixed and mobile communication, but we are not there today and I think someone should define intermediate solutions as SIP Trunking for plain old telephony. If this should be an objective for SIPConnect 1.1 or not is probably a valid question.

/Janne

________________________________

From: Francois Audet [mailto:audet at nortel.com] 
Sent: den 15 maj 2008 18:36
To: Henry Sinnreich; Janne Magnusson; Hadriel Kaplan; Zweig, Greg; Joanne McMillen; Russell Bennett; techwg at sipforum.org
Subject: RE: Focus on simple PSTN?

I agree with Henry.

Also, I sense that a lot of people seem to be seeing this as an exercise to document current practice (with all their limitations), as opposed to best practices for implementors.

I think the days where "basic PSTN equivalency" was the goal are long gone. I hope we will not "undershoot" and produce as spec that is not ambitious enough.

________________________________

	From: Henry Sinnreich [mailto:hsinnrei at adobe.com] 
	Sent: Thursday, May 15, 2008 09:20
	To: Janne Magnusson; Hadriel Kaplan; Zweig, Greg; Audet, Francois (SC100:3055); Joanne McMillen; Russell Bennett; techwg at sipforum.org
	Subject: Focus on simple PSTN?

	>The base level will be focused on simple PSTN connectivity were a SIP Trunk replaces the PRI and the extended level looks 
	>beyond that with additional services and trunking directly between organizations. 

	Please forgive my naïve question, but is this not like trying to remake history?

	At a time when everyone carries and prefers their mobile device and unified communications on the Internet?
	All I see in industry reports is how many landline customers are abandoning the "regular" phones...

	BTW: I was one of the founders of the SIP Forum and can attest this was not the vision we had for SIP; to connect landline desk phones to carriers.
	Most of my colleagues rub around with their Blackberry (I use my the Nokia N810) or look at something on the web.
	How many folks on this list have ever forwarded a call from their mobile phone?
	If trunking PBX's at all, why not to mobile service providers and why not directly over the Internet?

	Please feel free to flame these questions.

	Thanks, Henry

	On 5/15/08 2:05 AM, "Janne Magnusson" <janne at ingate.com> wrote:

	Hi

	All our experience with SIP Trunking deployments tells that UDP, G.711/G.729 are used in almost every installation. So support for transport over UDP should be mandatory as well as support for G.711, I haven't seen any SP not supporting G.711. G.729 should probably also be mandatory as many SPs prefer it to save bandwidth. If any of these are omitted as mandatory requirements it will take a long time before SC1.1 is anywhere close to widely deployed. 

	To accept the above might be a bit limiting and too conservative, but it is necessary if we want anything that can be widely deployed soon with an ambition that it should work like plug-and-play. At the same time I think the specification should be more forward looking and suggest standards and best practice for increased security and functionality (TLS, SRTP, wideband codecs, video etc). To achieve this I think we need to consider something along the lines of Russell suggestion to have two levels of the specification, a base level defining the common-denominator looking at the products and services available today, and an extended level that is less strict and allows for more new features. The base level will be focused on simple PSTN connectivity were a SIP Trunk replaces the PRI and the extended level looks beyond that with additional services and trunking directly between organizations. 

	/Janne

________________________________

	From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] <mailto:techwg-bounces at sipforum.org%5d>  On Behalf Of Hadriel Kaplan
	Sent: den 15 maj 2008 06:21
	To: Zweig, Greg; Francois Audet; Joanne McMillen; Russell Bennett; techwg at sipforum.org
	Subject: Re: [SIPForum-techwg] SIPConnect 1.1 -Microsoft proposalandadditional requirements- TCP

	I agree with Greg - while we all see the need and desire to go to TCP, the fact of the matter is UDP dominates it by several orders of magnitude.  And it's not just the PBX side: it's in the core, it's PSTN gateways, peering connections, etc.  Ignoring it will be about as successful as mandating TLS was for SIP-Connect 1.0 - it was defined as a MUST, but the vast majority if not outright unanimity of 1.0 usage doesn't end up using TLS. I think we need to mandate support for both TCP and UDP, and recommend TCP, but allow UDP.

	I also agree with his assessment of G.722.1.  The low bandwidth codec needs are far more commonly handled with G.729, not G.722.1.  If we want to pick two lowest-common-denominator type codecs, which I agree would be useful, it would be G.711 and G.729 hands-down, imho.

	-hadriel

________________________________

	From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] <mailto:techwg-bounces at sipforum.org%5d>  On Behalf Of Zweig, Greg
	Sent: Wednesday, May 14, 2008 5:58 PM
	To: Francois Audet; 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] <mailto:techwg-bounces at sipforum.org%5d>  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] <mailto:joanne at avaya.com%5d>  
		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> <mailto:audet at nortel.com>   

			To: Joanne McMillen <mailto:joanne at avaya.com> <mailto:joanne at avaya.com>   ; Russell Bennett <mailto:Russell.Bennett at microsoft.com> <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] <mailto:techwg-bounces at sipforum.org%5d>  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> <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> <mailto:russben at microsoft.com>  
				sip:         russben at microsoft.com <mailto: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/20080515/ea508b35/attachment-0001.html 