[SIPForum-discussion] E.164

Wed Sep 9 09:33:42 UTC 2015

Good day.

To confirm,  does E164 mean a + be added in front of country code?

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Joel Gerber
Sent: 21 August 2015 04:04 PM
To: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] E.164

If the standard says the maximum is 15 digits, then 15 digits should be the
maximum. If they fail to meet the standard, then your vendor should not be
surprised if interoperability issues arise.

Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
 <mailto:%20Joel.Gerber at corp.eastlink.ca> Joel.Gerber at corp.eastlink.ca    T:
519.786.1241

From: Harshith Mulky [mailto:harshith.mulky at outlook.com] 
Sent: August-21-15 9:59 AM
To: Paul Kyzivat <pkyzivat at alum.mit.edu <mailto:pkyzivat at alum.mit.edu> >;
Joel Gerber <Joel.Gerber at corp.eastlink.ca
<mailto:Joel.Gerber at corp.eastlink.ca> >; discussion at sipforum.org
<mailto:discussion at sipforum.org> 
Subject: RE: [SIPForum-discussion] E.164

Sorry for deviating from the topic, 
I would want to know, if Characters are allowed in E164 Numbering format, if
so, what is the maximum characters allowed? 
Does it make sense to allow characters in E164 Format

I ask because one of our Vendors use E164 Format much larger than what is
specified in E164 specifications

The Specs tell

"Subscriber numbers are the remaining digits that follow the shared country
code and the IC. The
structure and functionality is determined by the operator. The maximum
length of the subscriber
number is 15 minus the total of the CC and IC digits."

I was confused. Could anyone please clarify?

Thanks
Harshith

> Date: Wed, 19 Aug 2015 18:28:46 -0400
> From: pkyzivat at alum.mit.edu <mailto:pkyzivat at alum.mit.edu> 
> To: Joel.Gerber at corp.eastlink.ca <mailto:Joel.Gerber at corp.eastlink.ca> ;
discussion at sipforum.org <mailto:discussion at sipforum.org> 
> Subject: Re: [SIPForum-discussion] E.164
> 
> On 8/19/15 3:45 PM, Joel Gerber wrote:
> > Hello Paul &etc,
> >
> > I will say this much, some of your invalid SIP URI formats are commonly
being used in industry today. Particularly sip:NPANXXDEFG at proxy;user=phone.
> 
> I'm quite aware that such things are in use. That doesn't make them 
> correct. If you read the specs you will see that when user=phone is 
> present then the user part should conform to the tel URI format. And the 
> tel format requires that a number starting with a digit also have a 
> phone-context param.
> 
> There are no protocol police. So you can use whatever you want, if it 
> works for you. But then you shouldn't claim conformance to the specs you 
> are violating. If an interop problem arises, you are then on your own.
> 
> > Also, the specification between domestic and international calls is not
determined by the dialed or signalled digits. It's the responsibility of the
telephony switch receiving these dialed digits to determine this for itself
based upon its dial peer/translations configuration. When you consider the
context of E.164 formatted digits, you can have +countrycodephonenumber
digits even if the call is to your next door neighbour.
> 
> I agree.
> 
> These days it ought to be quite common to see "local" calls made using 
> E.164 numbers. For instance, it makes a lot of sense to populate the 
> address book on your phone solely with E.164 numbers. That way they will 
> work regardless of where they are used.
> 
> (That may not be a problem for people who spend all their time in one 
> country.)
> 
> Thanks,
> Paul
> 
> > Joel Gerber
> > Network Operations Specialist - Telephone
> > Telephone
> > Eastlink
> > Joel.Gerber at corp.eastlink.ca <mailto:Joel.Gerber at corp.eastlink.ca>  T:
519.786.1241
> >
> > -----Original Message-----
> > From: discussion-bounces at sipforum.org
<mailto:discussion-bounces at sipforum.org>
[mailto:discussion-bounces at sipforum.org] On Behalf Of Paul Kyzivat
> > Sent: August-17-15 11:39 AM
> > To: discussion at sipforum.org <mailto:discussion at sipforum.org> 
> > Subject: Re: [SIPForum-discussion] E.164
> >
> > This is considerable mis-information in this thread.
> > Brian is correct.
> >
> > In sip there are a few ways to identify a target by "phone number", and
there are a couple of dimensions to it.
> >
> > First, you can identify the target using either a "tel:" URI or a "sip:"
> > or "sips:" URI. For sip or sips URIs there are a few options:
> >
> > * the "phone number" will be in the user part of the URI.
> > The way that part is formatted and understood depends on
> > the value of the "user=" uri-parameter.
> >
> > * for "user=phone", the user part is interpreted the same as
> > the body of a tel URI. (See below for more on this.)
> >
> > * for "user=ip", the user part is interpreted in some domain
> > specific way. (This is often considered to be like an "email-style"
> > URI format.) It *could* be treated as a phone number, but whether
> > it is or not is a policy decision for the domain of the URI.
> > This is the default if there is no user= parameter.
> >
> > * for "user=dialstring", the user part contains a "dial string".
> > Namely the string of "digits" dialed, along with some context
> > to help disambiguate the dial string. This format is defined
> > by RFC4967. (Authored by Brian.)
> >
> > For a tel: URI (defined by RFC3966):
> >
> > * The number can be a "global-number" or a "local-number".
> >
> > * global-numbers is in E.164 format. *All* global-numbers
> > start with "+".
> >
> > * local-numbers do not start with "+".
> >
> > * both global and local numbers may have parameters following
> > the number. Local numbers *must* have a "phone-context"
> > parameter. This provides a globally unique context in which
> > the "number" can be understood unambiguously.
> >
> > The following are some implications/examples of the above:
> >
> > 1) sip:+12125551234 at example.com;user=phone
> >
> > This is a well formed E.164 phone number URI.
> >
> > 2) tel:+12125551234
> >
> > This identifies the same phone number as (1), but doesn't say
> > what domain should be used to reach it.
> >
> > 3) sip:2125551234;phone-context=+1 at example.com;user=phone
> >
> > This is a local-number in the context "+1".
> >
> > 4) sip:2125551234;phone-context=example.org at example.com;user=phone
> >
> > This is an alternative way to represent phone context.
> >
> > 5) sip:711;phone-context=+1 at example.com;user=phone
> >
> > This is one potential way to represent non-E.164 numbers.
> >
> > 6) sip:1234;phone-context=foo.com at example.com;user=phone
> >
> > This is a potential way for a company to represent a local
> > extension on their pbx that has no E.164 number. In this form
> > it *can*, in principle, be used outside the foo.com network
> > and still remain unambiguous.
> >
> > 7) sip:912125551234;phone-context=foo.com at example.com;user=dialstring
> >
> > This is a way to transform a dialed string of digits into a URI
> > without having to interpret it in any way. Note that, as with
> > local numbers, the phone-context is *required*. It provides the
> > context within which to understand the dial plan.
> >
> > 8) sip:8888 at example.com;user=ip
> >
> > This might be meaningful in a domain that uses numeric user ids.
> > (I don't know if there are any of those left, but there might be.)
> > There is no a priori assumption that the 1234 is a "phone number".
> >
> > 9) sip:8888 at example.com
> >
> > This has *exactly* the same meaning as (8).
> >
> > 10) sip:2125551234 at user.com
> >
> > This should be understood the same way as (9). You can't assume
> > that this is a phone number unless you have some implicit contextual
> > information that user.com treats it that way.
> >
> > 11) sip:+12125551234 at user.com
> >
> > Same as (10).
> >
> > 12) sip:2125551234 at example.com;user=phone
> >
> > This is an invalid URI!
> > Because of the "user=phone", the user part is to be parsed according
> > to the tel uri format. Since it doesn't begin with "+", it is
> > required to have a phone-context parameter.
> >
> > 13) sip:912125551234 at example.com;user=dialstring
> >
> > This is also an invalid URI!
> > Again, a phone-context is required here. A dial string can only
> > be understood in a context that defines the dial plan.
> >
> > None of this says anything about "domestic" vs. "international" calling.
> >
> > I guess domestic calling is when both the caller and the callee are
identified by phone numbers in the same country code. But note that the URI
formats require all the URIs to be globally unambiguous. That can be by
having the country code as the prefix of the global number, or idenfified in
some way by the phone-context of a local number.
> >
> > The place where this becomes a meaningful concern is if you are using
URIs like (10). That URI can't be understood unambiguously as a phone number
unless you *know* that example.com intends it to be understood that way and
also understand what country code is to be used.
> >
> > Such usage is *allowed* by the specs, but the meaning is not defined by
the specs. IMO this is an unwise usage. If you intend to use it, then you
must carefully define your conventions and ensure that everyone that sees
such a URI follows those conventions.
> >
> > Thanks,
> > Paul
> >
> > On 8/16/15 9:50 AM, Shah Hussain Khattak wrote:
> >> Adding a few comments in below answers. The +1 is usually added to
> >> originated calling numbers in case the call is going to some
> >> destination outside of US, it's a well know feature ( in Sonus SBCs
> >> its called Number globalisation feature at trunk groups level), and
> >> this could be replicated for different countries. It's only for
> >> international call termination, the calling number is appended with
> >> originating country code....
> >>
> >> Sent from my iPhone
> >>
> >> On 16-Aug-2015, at 12:29 am, Stoller, Jeff
> >> <Jeff_Stoller at cable.comcast.com
<mailto:Jeff_Stoller at cable.comcast.com%0b> 
> >> <mailto:Jeff_Stoller at cable.comcast.com>>
> >> wrote:
> >>
> >>> +1 is domestic E.164 format. + and then the number is for
> >>> international. To convert a US phone number like 415 555 2671 to
> >>> E.164 format, you need to add the '+' prefix and the country code
> >>> (which is 1) in front of the number so it will look like +14155552671.
> >>>
> >>> *From:*discussion-bounces at sipforum.org
> >>> <mailto:discussion-bounces at sipforum.org>
> >>> [mailto:discussion-bounces at sipforum.org] *On Behalf Of *Anthony
> >>> Orlando
> >>> *Sent:* Wednesday, July 29, 2015 12:37 PM
> >>> *To:* SIP Forum
> >>> *Subject:* [SIPForum-discussion] E.164
> >>>
> >>> Looking for some clarification. I have a vendor that claims +1
> >>> indicates an internationally originated call. I disagree and feel
> >>> that it is merely an indication that it is in E.164 format. Anyone
> >>> want to chime in?
> >>>
> >>> _______________________________________________
> >>> This is the SIP Forum discussion mailing list TO UNSUBSCRIBE, or edit
> >>> your delivery options, please visit
> >>> http://sipforum.org/mailman/listinfo/discussion
> >>> Post to the list at discussion at sipforum.org
<mailto:discussion at sipforum.org> 
> >>> <mailto:discussion at sipforum.org>
> >>
> >>
> >> _______________________________________________
> >> This is the SIP Forum discussion mailing list TO UNSUBSCRIBE, or edit
> >> your delivery options, please visit
> >> http://sipforum.org/mailman/listinfo/discussion
> >> Post to the list at discussion at sipforum.org
<mailto:discussion at sipforum.org> 
> >>
> >
> > _______________________________________________
> > This is the SIP Forum discussion mailing list TO UNSUBSCRIBE, or edit
your delivery options, please visit
http://sipforum.org/mailman/listinfo/discussion
> > Post to the list at discussion at sipforum.org
<mailto:discussion at sipforum.org> 
> >
> 
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
<mailto:discussion at sipforum.org> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20150909/2d7408a7/attachment-0002.html>