Subject: [Speermint] Requirement(s) for call routing addressing data variability (was: RE: [Speermint] Basic Peering Requirements)

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 18 Oct 2006 10:02:16 -0600

Otmar wrote:
> I still think we need to work out and then nail down what the
> requirements are for the routing decisions which we face in
> the speermint context.

Daryl wrote:
> | From what I have gleaned from network operators, they do want to
> | tell their peering partners (independently of other peerings) quite
> | explicitely to which ingress point they should connect to.

Brian wrote:
> Mostly, I see federations allowing per peer-pair variability in their
> registry, whether it's an ENUM database, a SIP redirect, a SIP Forward
> or
> some other mechanism.  The result is the same, for a given peer as
> origination to a specific peer as termination, a specific (list of)
> proxy
> server domain name(s) is provided.  Usually, there aren't n squared
> values,
> but in theory there could be.

I would like to capture a few requirements here using the updated
terminology available in draft-ietf-speermint-terminology-06.txt.

This discussion is about the call addressing data and its variability
depending on:
	- how the data is acquired: 
the originator of the ENUM query, the target e.164 address => this seems
to do with the acquisition of call addressing data (or LF in the
proposed architecture): this is out of scope of speermint I think;
	- how it is resolved:
How the call routing data elements are resolved the resolution of that
call addressing data into something that leads to the establishment of a
sip session (relates to PF, SF). This is where I believe we should
develop those requirements.
==> this dichotomy seems reductive but it is somewhat imposed by the way
we've looked at things so far. Is this a correct interpretation of
what's discussed here?

If so, are the following requirements capturing what you meant above?
Any help in improving these to cover the cases you mentioned is
appreciated.
- A terminating VSP/ASP or user SHOULD be able to indicate its domain
ingress points (Signaling Path Border Element(s)) based on the identity
of the originating VSP/ASP/user

Another high-level design guideline could be:
- The mechanisms recommended for the use and resolution of the call
addressing data SHOULD allow for variability/customization depending on
various factors, such as the identity of the originating or terminating
peers.

Comments appreciated.

Jean-Francois.

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

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Wed, 18 Oct 2006 12:25:45 -0400

Yes, I think this captures an important need.

Penn Pfautz 

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2006 12:02 PM
To: [email-masked]
Subject: [Speermint] Requirement(s) for call routing addressing
datavariability (was: RE: [Speermint] Basic Peering Requirements)

Comments appreciated.

Jean-Francois.

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 18 Oct 2006 12:56:34 -0400

Jean-Francois - well done shifting through all the noise to get at the
key requirements across 3 different voices!  
Couple comments:
 - I need to ask why you think the LF function is out of scope?  Are you
thinking that it's out of scope for speermint, but in scope for
ENUM/DNS?  
 - I also think the comment about how call addressing data is acquired
is via user input - regardless if it is E.164 or an URI.  It's not
really an issue as the session has to start somewhere with something.
It's the resolving of the data input that needs the attention both in
speermint/ENUM/DNS/SIP/etc.

Otmar - requirements for the routing decisions
Daryl - Operators maintaining control of how sessions ingress to them
Brian - specific list of proxy server domain names between peers

None of these, from what I can glean, have anything to do with how the
data is acquired - only the resolution once data is available.

-AU

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2006 12:02 PM
To: [email-masked]
Subject: [Speermint] Requirement(s) for call routing addressing

Otmar wrote:
> requirements are for the routing decisions which we face in the 
> speermint context.

> or some other mechanism.  The result is the same, for a given peer as 
> proxy server domain name(s) is provided.  Usually, there aren't n 
> squared values, but in theory there could be.

Comments appreciated.

Jean-Francois.