Subject: [Speermint] Some thoughts on the architecture document

From: Otmar Lendl <[email-masked]>
Date: Mon, 22 Mar 2010 23:39:15 +0100

I'm nor sure I'll stay awake for the session, thus some input via mail:

>   This document assumes that in order for a session to be established
>   from a User Agent (UA) in the Originating SSP's network to a UA in
>   the Target SSP's network the following steps are taken:

So the transit case is disregarded in this document?

>   2.  Determine the address of the SF of the target SSP via the LRF.

What about putting the "determine the right SBE on the originating side"
question in here? (cf. Daryl's outbound draft and the discussion in DISPATCH)

>   If the target SSP is also an indirect peer, then steps 1-4 may be
>   repeated.  This is reflected in Figure 1 that shows the target SSP
>   with its own peering functions.

Ah, so we do transit after all?

"target" is now the next hop or the ultimate SSP? (haven't we been talking
about that 3 years ago? still no clear definition / better wording on this?)

I don't understand what the second sentence is supposed to mean.

>   Also, the SSP may skip actual DNS queries if the target domain is
>   represented as an IPv4/v6 address.

Hu? We're talking about making ENUM queries based on E.164 numbers.

> 5.1.2. Location Routing Function (LRF)

Once again, "target" can be a bit ambiguous and (again) perhaps don't just
talk about the SF of the next hop, but also the SF inside the originating
SSP which can talk to that nexthop SF. (the outbound proxy problem)

>   Communication between the LRF of two interconnecting SSPs may use DNS
>   or statically provisioned IP Addresses for reachability.

Do two LRFs talk to each other? That's actually a good idea but I don't
think this is the intended meaning. What this sentence is supposed to mean
eludes me.

---------

What's missing are a few words on the possible (and perhaps recommended)
URIs/AoRs/adresses used at various states in the process, especially in the
transit case.

e.g.: What should the output of the ENUM lookup be?

a) a SIP AoR (e.g. sip:[email-masked])
b) a SIP location URI like sip:[email-masked]
c) just a SSP ID (ITAD, domain, ...)

What does the LRF yield and how is the request rewritten/rerouted?

c) do a) -> b) and retarget the call
d) leave a) in the request URI and just add a suitable Route: header (just
affect the next SIP message destination)
e) leave a tel: URI in the request URI and add Route header
f) NOP, if we had case b)

In the indirect peering case what does the LUF do?

g) return the same info regardless if a peering relationship exists (let
the LRF sort it out)
h) make it look like the destination is inside a peering SSP (in essence,
the LUF is playing proxy ARP)

(in both cases, options a,b, or c still need to be sorted out)

In the indirect peering, is the next hop supposed to repeat the ENUM query?
If b) or c), then yes. But how will he retrieve the E.164 number? For that,
b) needs to have the number as the user-part.

----------

All in all, this document is a nice writeup on some of the questions raised
by SIP peering, but I doubt it's much of a help to people who actually are
builing these peering relationships. It's far too generic for that.

cheeer,

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Mon, 22 Mar 2010 18:45:47 -0400

The text in question was not for LRF-LRF.it was for 5.1.2.3

Penn Pfautz
AT&T Access Management
+1-732-420-4962

---

From: Adam Uzelac <[email-masked]>
Date: Mon, 22 Mar 2010 15:52:59 -0700

At the meeting here - that section LRF to LRF - will be removed, or rather
folded into the sections directly preceding it.  The original intention of
that section is unclear.

-Adam

On Mon, Mar 22, 2010 at 3:45 PM, PFAUTZ, PENN L (ATTCORP) <[email-masked]>wrote:

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

---

From: Daryl Malas <[email-masked]>
Date: Mon, 22 Mar 2010 20:13:42 -0600

Otmar,

Good feedback.  FYI...Adam will be editing the document for the next revision.

Best Regards,

Daryl
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Otmar Lendl [[email-masked]]
Sent: Monday, March 22, 2010 4:39 PM
To: [email-masked]
Subject: [Speermint] Some thoughts on the architecture document

---------

----------

cheeer,

otmar