Subject: [Speermint] RE: I-D ACTION:draft-elwell-speermint-enterprise-usecases-00.txt

From: "Stastny Richard" <[email-masked]>
Date: Mon, 19 Feb 2007 14:05:59 +0100

Many thanks to the authors for this draft,
claryfing the position of enterprise peering

This fits very well to the recent discussions
on the list if enterprise peering should be 
treated differently or not.

Some questions and comments:

1. I assume that Enterprise A may select the
peering based on analysing the domain name of
the SIP URI. Some domains may peer directly, some
may peer via a carrier I.

Is it also possible that an Enterprise A may peer
with more than one carrier. And if yes,
how does Enterprise A distinguish between the carriers

2. In section 5.1 you mention E.164-based URIs
and non-E.164-based URI. I assume you mean here
plain SIP URIs. The term non-E.164-bases URIs
is ambiguous, because there are also non-E.164 
phone numbers.

3. In 5.3 Routing you mention that Enterprises
want to use domain names on their own (example.com)

OTOH, if using E.164 numbers, you will also have
to use the domain of the peering Carrier for incoming calls
I think this issue requires further study, especially in the
context of Infrastructure ENUM and also with Calling and 
Connected Identities.

Best regards
Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 16, 2007 9:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-elwell-speermint-enterprise-usecases-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Use cases for Enterprise Peering using the
Session
> Initiation Protocol (SIP)
> 	Author(s)	: J. Elwell, B. Rodrig
> 	Filename	:
draft-elwell-speermint-enterprise-usecases-00.txt
> 	Pages		: 15
> 	Date		: 2007-2-16
> 
>    Work in the SPEERMINT Working Group has focused to some extent on
>    peering between carrier VoIP Service Providers (VSP).  This draft
>    describes some use cases involving SIP peering between enterprise
>    VSPs, with and without the involvement of carrier VSPs, and also
>    peering between enterprise VSPs and carrier VSPs.  It also
discusses
>    some of the key technical considerations applicable to these use
>    cases.
> 
>    This work is being discussed on the [email-masked] mailing
list.
> 
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-elwell-speermint-enterprise-us
ecases-00.txt

> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-elwell-speermint-enterprise-usecases-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE
/internet-drafts/draft-elwell-speermint-enterprise-usecases-
> 00.txt".
> 
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 19 Feb 2007 09:27:27 -0500

> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Monday, February 19, 2007 8:06 AM
> To: [email-masked]
> Subject: [Speermint] RE: 
> I-DACTION:draft-elwell-speermint-enterprise-usecases-00.txt 
> 
> Many thanks to the authors for this draft, claryfing the 
> position of enterprise peering
> 
> This fits very well to the recent discussions on the list if 
> enterprise peering should be treated differently or not.
> 
> 1. I assume that Enterprise A may select the peering based on 
> analysing the domain name of the SIP URI. Some domains may 
> peer directly, some may peer via a carrier I.
> 
> Is it also possible that an Enterprise A may peer with more 
> than one carrier. And if yes, how does Enterprise A 
> distinguish between the carriers

The choice of which carrier to peer with could depend on the target of
the communications and the possibility that the target has also
identified that carrier as a peer.

If no such relationship exists, then other criteria could be used to
select an outgoing carrier.

Conversely, an incoming communications could depend on the source having
a relationship with a carrier that is also listed by Ent-A as having a
peering relationship.

> 2. In section 5.1 you mention E.164-based URIs and 
> non-E.164-based URI. I assume you mean here plain SIP URIs. 
> The term non-E.164-bases URIs is ambiguous, because there are 
> also non-E.164 phone numbers.

You may be confusing dialing strings versus an expanded E.164 nubmer.
If it is just a string, then likely there is no difference from an
arbitrary string as user-part of a SIP address.  If so, there is no need
to distinguish from a SIP address since lookups and routing should be
base on the host-part.

> 3. In 5.3 Routing you mention that Enterprises want to use 
> domain names on their own (example.com)
> 
> OTOH, if using E.164 numbers, you will also have to use the 
> domain of the peering Carrier for incoming calls I think this 
> issue requires further study, especially in the context of 
> Infrastructure ENUM and also with Calling and Connected Identities.

Are you saying that <E.164>@example.com is not permitted?  
Why?  You need to study that assertion first.

Mike

> > Subject: I-D 
> ACTION:draft-elwell-speermint-enterprise-usecases-00.txt
> > 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > logging in, type "cd internet-drafts" and then "get 
> > draft-elwell-speermint-enterprise-usecases-00.txt".
> > 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 19 Feb 2007 15:58:21 +0100

> to distinguish from a SIP address since lookups and routing should be

Not all dialling string expand to E.164 numbers, I just wanted to
mention
that there are also dialling string which expand to non-E.164 numbers
such as 112, 911 and others
> Why?  You need to study that assertion first.
See my reply to John

Richard