[SIPForum-techwg] SIP URI formats for North America

Thu Sep 25 12:56:12 EDT 2008

URI

sip:+1NPANXXXXXX at host;user=phone

Description

NANP number

Reference

IETF RFC3966

Headers

R-URI, To, From, Request Contact, 3XX Contact, PAI, Diversion

URI

sip:+18YYXXXXXXX at host;user=phone

Description

NANP 8YY number

Reference

IETF RFC3966

Headers

R-URI, To, 3XX Contact

URI

sip:+1NPA5551212 at host;user=phone

Description

NANP Directory Assistance in global number format

Reference

IETF RFC3966

Headers

R-URI, To, 3XX Contact

URI

sip:0;phone-context=+1 at host;user=phone

Description

NANP operator requested in local number format

Reference

IETF RFC3966

Headers

R-URI, To, 3XX Contact

URI

sip:0NPANXXXXXX;phone-context=+1 at host;user=phone

Description

NANP operator requested in local number format

Reference

IETF RFC3966

Headers

R-URI, To, 3XX Contact

URI

sip:00;phone-context=+1 at host;user=phone

Description

NANP long distance operator requested in local number format

Reference

IETF RFC3966

Headers

R-URI, To, 3XX Contact

URI

sip:+1NPANXXXXXX;npdi at host;user=phone

Description

NANP number with Number Portability Dip Indicator

Reference

http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-09.txt

Headers

R-URI, To, 3XX Contact

URI

sip:+1NPANXXXXXX;rn=+1NPANXXXXXX;npdi at host;user=phone

Description

NANP number with Number Portability Dip indicator and LRN

Reference

http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-09
<http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-0509>  .txt

Headers

R-URI, To, 3XX Contact

URI

sip:+1NPANXXXXXX;cic=+10288 at host;user=phone

Description

NANP number with Carrier Identification Code, NPA may be an 8YY

Reference

http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-09.txt

Headers

R-URI, To, 3XX Contact

URI

sip:+1NPANXXXXXX;cic=+10288;dai at host;user=phone

Description

NANP number with Carrier Identification Code
and dial around indicator; NPA may be an 8YY

Reference

http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-09.txt

PKT-SP-CMSS-I03-040402 PacketCableTM 1.2 Specifications

Headers

R-URI, To, 3XX Contact

URI

sip:+1NPANXXXXXX at host;user=phone;isup-oli=0

Description

NANP number with OLI

Reference

From

URI

sip:+1NPANXXXXXX;rn=+1NPANXXXXXX at host;user=phone

Description

NANP number with JIP (used in a From, PAI, or Diversion header)

Reference

Headers

From, PAI, Diversion

URI

sip:N11;phone-context=+1 at host;user=phone

Description

NANP special service code in local number format

Reference

IETF RFC3966

Headers

R-URI, To, 3XX Contact

URI

sip:613131;phone-context=+1 at host;user=phone

Description

NANP directory assistance in local number format

Reference

IETF RFC3966

Headers

R-URI, To, 3XX Contact

URI

sip:+CCNSN at host;user=phone

Description

International number, CC=Country Code, NSN=National Significant
Number

Reference

IETF RFC3966

Headers

R-URI, To, From, Request Contact, 3XX Contact, PAI, Diversion

URI

sip:B;phone-context=+33 at host;user=phone

Description

 Directory assistance in local number format in country with CC 33

Reference

IETF RFC3966

Headers

R-URI, To, 3XX Contact

________________________________

From: Eric Burger [mailto:eburger at sipforum.org] 
Sent: Thursday, September 25, 2008 10:19 AM
To: Dan York; DOLLY, MARTIN C, ATTLABS
Cc: techwg at sipforum.org
Subject: Re: [SIPForum-techwg] Close off new comments to 1.0 effort on
12Noon EST Tommrrow

I 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.

Do note, that as mentioned in bullet 3, if we cannot quickly come to
consensus on a topic that is PSTN versus SIP cloud termination, we will
err on PSTN termination for this version of SIPconnect. That is why I'm
not a fan of "or SIP Enterprise Applications", as that opens the door
for long, drawn-out ratholes on theories over practice.

Just a personal opinion.

AND, THANKS FOR SUBMITTING TEXT. MAY YOU BE AN EXAMPLE TO EVERYONE ON
THE LIST!!!

On Sep 25, 2008, at 8:04 AM, Dan York wrote:

	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/74657b6e/attachment-0001.html 