[SIPForum-techwg] Close off new comments to 1.0 effort on 12Noon EST Tommrrow
Dan York
dyork at voxeo.com
Thu Sep 25 10:04:55 EDT 2008
Eric,
As much as I am a strong advocate of end-to-end connectivity and want
to do everything possible to build the massive SIP-SIP interconnect, I
do have to (gasp) agree with the esteemed Mr. Dolly here that the
scope of SIPconnect *today* really needs to focus on Enterprise <-> SP
connectivity. I agree with you that if we can get in features for SIP-
SIP connectivity that don't bog us down, we should do so. However I
do think we need to be crystal-clear that SIPconnect 1.1 is all about
doing the "SIP trunking" from an enterprise to a SIP Service Provider.
My point was that in the abstract, the Sept 22 document states:
-------------------
The SIPConnect 1.1 Technical Recommendation outlines an interface
specification that enables direct connectivity between a SIP-enabled
Service Provider network and a SIP-enabled Enterprise Network for the
purpose of originating and/or terminating calls from the Public
Switched Telephone Network (PSTN).
-------------------
while I would suggest it should read more like:
-------------------
The SIPConnect 1.1 Technical Recommendation outlines an interface
specification that enables direct connectivity between a SIP-enabled
Service Provider network and a SIP-enabled Enterprise Network.
-------------------
For perhaps MOST users of the SIPconnect 1.1 specification, the usage
*will* be for PSTN connectivity. However, there are certainly
circumstances where the usage may be for interconnection of a premise
SIP system to a SIP cloud for other services such as providing
applications. To give a specific example, I could see the case where a
SIPconnect compliant IP-PBX wanted to be able to do a "SIP trunk" to
Voxeo's (hopefully at that point SIPconnect-compliant) hosted SIP
application platform. The call might flow to our application server,
have some application executed and then flow back to the on-premise IP-
PBX. All via SIP... and all without touching the PSTN.
Maybe I'm getting too pedantic or nuanced here - and I don't mean to
take us down a rathole - but I would suggest that the abstract of the
document should not necessarily focus *exclusively* on PSTN
connectivity.
Perhaps another way to say it is:
-------------------
The SIPConnect 1.1 Technical Recommendation outlines an interface
specification that enables direct connectivity between a SIP-enabled
Service Provider network and a SIP-enabled Enterprise Network. Such
connectivity may be for the purpose of originating and/or terminating
calls from the Public Switched Telephone Network (PSTN) or for
accessing SIP-based applications provided by the Service Provider.
-------------------
Again, I don't really want to create a rathole on the first paragraph
- I just don't want to limit the SIPconnect 1.1 spec to PSTN
connectivity.
Hoping-we-can-rapidly-move-beyond-paragraph-one,
Dan
On Sep 25, 2008, at 7:45 AM, DOLLY, MARTIN C, ATTLABS wrote:
> Eric,
>
> I strongly disagree. The enterprise customer that purchases these
> equipment will interconnect to a service provider for services and
> PSTN connectivity. The end-to-end principle did not quite work for
> the IETF, so I do not se it working here. You need to take the
> carrier into account, or this specification is not worth the paper
> it is written on.
>
> Cheers,
>
> Martin
>
> From: techwg-bounces at sipforum.org [mailto:techwg-
> bounces at sipforum.org] On Behalf Of Eric Burger
> Sent: Thursday, September 25, 2008 12:40 AM
> To: Dan York
> Cc: techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] Close off new comments to 1.0 effort
> on 12Noon EST Tommrrow
>
> Let us not forget: one of the founding tenents of the SIP Forum is
> the end-to-end principle.
>
> Some guidelines I'd like to see, unless someone squawks loudly:
> So long as doing something that works SIP-SIP does not bog us down
> (i.e., we get it for free), I am all for it.
> Moreover, we should not do anything in SIPconnect 1.1 that will be
> an obvious impediment to SIPconnect 2.0, which will have all of the
> cool SIP-SIP, presence, full video conferencing, and sens-o-rama
> content negotiation.
> However, if it looks like we are going to rathole on something that
> just is not germane to getting SIPconnect 1.1 done, then I, for one,
> would not object to the editor or chair to cut discussion and defer
> that particular item to SIPconnect 2.0.
>
> This does not mean we cannot have a discussion. Likewise, as far as
> I know, this is entirely a theoretical discussion, as I am not aware
> of anything we are doing in SIPconnect 1.1 that prevents SIP-SIP
> from just working.
>
>
>
> On Sep 23, 2008, at 12:00 PM, Dan York wrote:
>
>> Richard,
>>
>> I've not sent any specific comments before because many of the
>> comments I did have were picked up by various parties and it seemed
>> pointless to simply say "I agree".
>>
>> I will state, though, that I second the comments of John Elwell and
>> others that my view of SIPconnect is that it should be a reference
>> architecture for connecting a on-premise SIP system to a SIP Service
>> Provider. Period. This connection may or may not be for PSTN
>> origination or termination. That is certainly one of the reasons -
>> and may be the primary reason for many people - but it's not the only
>> reason. I think we're getting (slowly) to the point where there
>> *are*
>> valid cases of wanting to connect SIP systems to SIP Service
>> Providers
>> purely to link in to the existing SIP clouds.
>>
>> My other comment is that in section 7.1.6, I think we need to think
>> through whether other SIP messages beyond INVITE and REGISTER do need
>> authentication, etc. (For instance, I know of some usage of REFER
>> which would seem to need that authentication.)
>>
>> I look forward to the discussion on Thursday. Overall, I think the
>> document is looking great.
>>
>> Regards,
>> Dan
>>
>> On Sep 22, 2008, at 2:59 PM, Richard Shockey wrote:
>>
>>> Tuesday September 23, 2008 in advance of our Face to Face meeting on
>>> Thursday and Friday in Denver.
>>>
>>> This does not mean we are closing off comments in general, or
>>> afterwards,
>>> but we want to limit the discussion points to what we have in hand
>>> on
>>> Tuesday.
>>>
>>> After we meet and reach some consensus on the direction of the
>>> document
>>> Spencer will issue a new draft and we can hopefully start the
>>> process to
>>> closure.
>>>
>>> Richard Shockey
>>> Director, Member of the Technical Staff
>>> NeuStar
>>> 46000 Center Oak Plaza - Sterling, VA 20166
>>> PSTN Office +1 571.434.5651
>>> PSTN Mobile: +1 703.593.2683
>>> <mailto:richard(at)shockey.us>
>>> <mailto:richard.shockey(at)neustar.biz>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> techwg mailing list
>>> Send mail to: techwg at sipforum.org
>>> Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg
>>
>> --
>> Dan York, CISSP, Director of Emerging Communication Technology
>> Office of the CTO Voxeo Corporation dyork at voxeo.com
>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com
>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com
>>
>> Build voice applications based on open standards.
>> Find out how at http://www.voxeo.com/free
>>
>>
>>
>>
>>
>> _______________________________________________
>> techwg mailing list
>> Send mail to: techwg at sipforum.org
>> Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg
>
--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation dyork at voxeo.com
Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com
Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com
Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20080925/3731379d/attachment-0001.html
More information about the techwg
mailing list