Subject: Re: [martini] Evaluation of issues solved by martini-up

From: "Jack Burton" <[email-masked]>
Date: Mon, 25 Jan 2010 17:43:50 -0500

I tried replying earlier, but I think I had the address messed up.
 
I totally agree with Richard's comments.  When does a standards organization loose relevance?  I would argue that happens when its standards are not put into practice.
 
REGISTER is how the IP-PBX SIP Trunking world works today, and in SIPConnect we hope to make that work more consistently among vendors.  SSPs (and probably equipment vendors as well) would never implement PUBLISH because doing so could break what they are doing today.  They would continue in the "hodgepodge" of an ill-defined Registration method.
 
-Jack

>>> Richard Shockey <[email-masked]> 1/25/2010 14:17 >>>

I still wish folks would understand the underlying business issues that have driven folks to this point in the discussion. 

I fully understand how we got here. But MARTINI was not set up to endorse a pre-existing practice as-is. I'm sure there are organizations in this space that would be happy to rubber stamp vendor solutions without proper technical vetting. We're not that.

This is not a vendor specific solution. I did not think that existing 3GPP or TISPAN documented practice on implicit registration would qualify as rubber stamping.  That remark is frankly a bit insulting even considering its source. 

I'm going to assume that the fact this landed in the IETF's lap is an indication that the interested parties are seeking some level of IETF imprimatur that the resulting technique is consistent with the remainder of the protocol, and free of major security errors.

To be blunt we needed the Option Tag which requires a RFC.  The use of this methodology is IMHO consistent with 3261 and others on this list also believe that as well.  In thousands of field deployments there have been no reported security issues .. confusion ..yes certainly .  My principal concern at this moment is can the regex actually do what it is proposed to do and could be reasonably adopted by the relevant vendors and SSP that would use that even you are admiting that a REGISTER procedure properly defined would work. 

It is perfectly fair and reasonable to ask if a proposed IETF solution will actually deploy. In SIP and countless other instances there have been RFC adopted and no deployments due to a lack of proper understanding of actual operational conditions especially OSS/BSS issues those RFC's address.  

The deployed techniques don't qualify.
I beg to differ. There is nothing wrong with the IETF adopting existing practice based on real  field experience or incorporating it into the over all architecture if it can be demonstrated to work correctly. As it is now it does work but not as well as it should. Thats why we are having this excersise.   You refuse to admit the possibility that a radical solution could be ignored. Humm sort of like health care reform? 

The approaches simply have fundamental flaws that are too profound to paper over with an option tag. I can appreciate the expedience of addressing foundation problems by caulking the cracks in the walls, but also recognize that you've done nothing to solve the underlying problems when you do so.

I just view the issue differently there is a problem in the field that needs to be fixed and fixed fast..there is a much larger issue of data provisioning in SIP networks that the IETF SIP community is not addressing correctly,  hence this problem and many more to come. I certainly agree there is a much larger problem here that all of us have essentially created but is this the right time to tackle that meta problem. 

You're effectively arguing that we need to ratify hodgepodge solutions developed in the field or risk being ignored on this topic. I think we're better off risking being ignored if the only other option is blindly ratifying broken protocol extensions. Being ignored on this topic may yield irrelevance on this one topic; ratifying broken solutions leads to permanent irrelevance on all topics from now on.

Well again I totally reject your contention that its "broken" or that shaken would some how "break" SIP that is just rhetoric.  What we have now is some what cracked certainly but if the cure is worse than the disease than we haven't solved anything. 

/a

-- 
Richard Shockey
Shockey Consulting
Chairman of Board SIP Forum
Voice +1 703 593 2683
Skype etc : rshockey101

-------------------------------------------------------- 
The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain Cablevision proprietary information, which is privileged, confidential, or subject to copyright belonging to Cablevision. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof. 
--------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 16:50:24 -0600

On 1/25/10 4:43 PM, Jack Burton wrote:
> REGISTER is how the IP-PBX SIP Trunking world works today, and in 
> SIPConnect we hope to make that work more consistently among vendors.  
> SSPs (and probably equipment vendors as well) would never implement 
> PUBLISH because doing so could break what they are doing today.

Don't get hung up on martini-up's proposal to use PUBLISH. While it does 
solve a very real class of problems, that one relatively minor aspect of 
the draft is not the most important mechanism it proposes. The majority 
of the problems it solves involve the explicit signaling of AORs in the 
request, the definition of a mechanism that enables "one contact URI per 
AOR," and the congruence with previous uses of REGISTER by employing 
"contact routing" instead of "domain routing."

/a