[SIPForum-techwg] Focus on simple PSTN?

[Eric Burger]

inline :-)

On May 17, 2008, at 1:00 AM, Hadriel Kaplan wrote:

> Hey Eric,
> Comments inline...
>
>> -----Original Message-----
>> From: techwg-bounces at sipforum.org [mailto:techwg- 
>> bounces at sipforum.org] On
>> Behalf Of Eric Burger
>>
>> Speaking as an individual:
>> PLEASE take a look at Section 2.1.2 of:
>> http://www.ietf.org/internet-drafts/draft-iab-protocol-success-03.txt
>>
>> We don't want to take any steps backward.  For example, we don't want
>> to do the 3GPP thing of making protocol "profiles" that make it hard
>> or impossible to interoperate with non-walled-garden SIP devices.
>
> I am not sure what you mean by that.  Do you mean you don't think we  
> should create profiles?  Or that the profiles we create shouldn't  
> require things which are not already commonly used?  Or that the  
> profiles we create shouldn't restrict us to a specific set of  
> behaviors?

I hope we should create a profile, otherwise, what are we doing? <g>

What I am saying is the profile should not change SIP.  So, for this  
example, SIPconnect 1.1 can mandate TCP *only*.  However, a SIPconnect- 
compliant device must support RFC 3261.  That means it must support  
negotiation as well as UDP.

Given this, one might ask why I do NOT want to see something like the  
following in SIPconnect 1.1?
    Devices MUST support TCP (because it always works and TCP is
    fast enough on today's networks) and MUST support UDP (because
    RFC 3261 says we do).

The reason is that if SIPconnect talks about UDP, then we will be  
stuck with UDP *forever*.  I would offer this same argument for all of  
the other legacy experiments in SIP that have failed.  Let me again  
point out: SIP is *12* years since -00, and *9* years since RFC 2543.   
This may surprise some people, but some of the stuff that we took as  
gospel in the last century is simply wrong.  By the same token, a lot  
of stuff that people in the intervening years have tried to put in to  
make SIP in to "SS8" or "IP ISDN" is simply wrong, too.

I would offer we neither limit ourselves to the box of last century's  
experiments nor to the box of a 100-year-old PSTN.

So long as we viciously protect that one must be SIP compliant to be  
SIPconnect compliant, which keeps us out of the 3GPP trap, I (just as  
a contributor) would offer we stick to ONLY that which must be  
specified for the profile, AND NOTHING MORE.

What would be my list of "stuff for the profile"?
1. Things in SIP that are Optional but we need to be Mandatory.  Like  
SIPconnect only understands TCP.

2. Things necessary to make SIP work that are either under-specified  
or over-optioned, like SDP.

3. Things necessary to make the profile work, beyond things necessary  
to make SIP work, like ENUM.

4. Things necessary to make the profile deployable, like which SNMP  
MIBs, or new MIBs.


Note that our job for things in SIP that have multiple interpretations  
is to feed the info back to the IETF to correct SIP.  It is not in our  
charter to "profile"-away errors in IETF documents.



>> However, we do want people to be able to easily adopt the profile.
>> Part of that is some level of backward compatibility and ease of
>> deployment.  Do note that there is a limit of backward compatibility.
>> For example, if many devices out there support TCP, and most of the
>> typical devices found at the enterprise support TCP or are easily
>> upgradable to support TCP, then I would see no problem of mandating
>> TCP.  We don't need to support 10-year-old (or 10-year-old mindset)
>> UDP-only, RFC 2543 devices.  <just my vote>
>
> I agree we shouldn't need to support RFC2543 devices.  That is an  
> orthogonal issue with supporting UDP, imo.
>
> I think there is a distinction between what a vendor needs to  
> support to be able to claim compliance, and what a service provider  
> or Enterprise has to support/enable to claim compliance.  Those are  
> very different beasts.
>
> In terms of creating PICS Proforma compliance checklists, the value  
> for a SIP-Connect spec is different for those two meanings.  For the  
> vendor support case, the value is that an Enterprise or Service  
> Provider can know what they're buying/deploying can be used for SIP  
> Trunking services of this type.  I think we're all on that page.  I  
> don't think there is much debate that any vendor claiming compliance  
> to SIP-Connect must support TCP. (at least the vendors at the SSP- 
> Enterprise transport connection points)  They must also support  
> UDP.  Otherwise they will severely limit their usefulness to the  
> people buying them.
>
> -hadriel

Can the PICS Proforma be different?  Should it be?  Is there something  
more than "Vendors check-off they conform by supplying products that  
meet this checklist of stuff" and "Service Providers check-off they  
conform by supplying services that meet this checklist of stuff"?  Is  
the "checklist of stuff" different?  I honestly don't know - let me  
know!

BTW: for the chairs/editors: will we have a PICS Proforma in the  
document?