Subject: [Speermint] Clarification sought about LUF response data.

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 24 Feb 2010 17:28:02 +0100

As you probably know, DRINKS is working on a protocol that allows for
provisioning of data which is then returned as Session Establishment
Data in the chain of the LUF/LRF functions.

We're currently discussion what type of data the LUF should return (and
therefore, what type/kind of data is used as input data for the LRF).

The SPEERMINT documents are not consistent and entirely clear about
this. I'm right now looking only at RFC5486 (which is the most relevant
document for terminology, obviously), and even that document contradicts
itself in the definition (Section 4.3.3):

  "The Look-Up Function (LUF) determines for a given request the target
   domain to which the request should be routed.  An example of an LUF
   is an ENUM [4] look-up or a SIP INVITE request to a SIP proxy
   providing redirect responses for peers."

The first sentence says "it returns a domain", while the examples in the
second sentence indicate that it would return a full AoR? I know that a
sip: URI does not need to contain a user part, but it seems the much
more common case that ENUM or SIP redirect servers return sip: URIs
including a user part.

Looking at the ENUM and SIP redirect cases specifically, we think that a
typical useful LUF response would be as follows:

  tel:+19195551234 -> LUF -> sip:[email-masked]

rather than

  tel:+19195551234 -> LUF -> sip:voip.example.com

I think that the question is whether or not the LUF response *replaces*
the original URI, or rather *amends* it with the additional information.

It's also related to the question what data is fed into the LRF? Is the
only data fed into that function the response data from the LUF, or is
it both the LUF response plus the original URI, eg.:

 tel:+19195551234
   plus               ----> LRF --->  sip:[email-masked]:123
 sip:voip.example.com

With the "domain only" LUF response alone, the LRF could just return a
"generic" SF address that requires additional information to properly
route the session:

sip:voip.example.com  ----> LRF ----> sip:[email-masked]:1234

Therefore, it seems to us cleaner when the LUF returns a full AoR. It
would still fit the definition of "determining the target domain", it
just "copies" certain information from the input data to the output data.

Opinions and comments to clarify that?

Alex

---

From: Daryl Malas <[email-masked]>
Date: Wed, 24 Feb 2010 11:11:32 -0700

Alex,

The purpose of the definition is to say for a given request, +13035551212, the LUF determines the target domain, ssp.example.com; which, results in [email-masked].  The LRF determines for ssp.example.com the appropriate path to get there, for example:

$ORIGIN _sip._udp.ssp.example.com.
	IN   SRV  0   1   5060    big-sbe.ssp.example.com
	IN   SRV  1   1   5060    small-sbe.ssp.example.com
	IN   SRV  1   2   5060    old-big-sbe.ssp.example.com
big-sbe	A  192.168.5.5
small-sbe	A  192.168.4.5
old-big-sbe	A  192.168.100.5

Or, the LRF may return an egress route as described in draft-malas-enum-trunk-sip-01, for example: 

$ORIGIN 2.1.2.1.5.5.5.3.0.3.1.e164.arpa.
      NAPTR 10 100 "u" "E2U+sip"  "!^.*$!sip:\1;tgrp=TG-1;trunk-context=ssp2.example.com  @big-sbe.ssp.example.com;user=phone!" .

Regards,

Daryl 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Wednesday, February 24, 2010 9:28 AM
To: [email-masked]
Subject: [Speermint] Clarification sought about LUF response data.

As you probably know, DRINKS is working on a protocol that allows for provisioning of data which is then returned as Session Establishment Data in the chain of the LUF/LRF functions.

We're currently discussion what type of data the LUF should return (and therefore, what type/kind of data is used as input data for the LRF).

The SPEERMINT documents are not consistent and entirely clear about this. I'm right now looking only at RFC5486 (which is the most relevant document for terminology, obviously), and even that document contradicts itself in the definition (Section 4.3.3):

The first sentence says "it returns a domain", while the examples in the second sentence indicate that it would return a full AoR? I know that a
sip: URI does not need to contain a user part, but it seems the much more common case that ENUM or SIP redirect servers return sip: URIs including a user part.

Looking at the ENUM and SIP redirect cases specifically, we think that a typical useful LUF response would be as follows:

rather than

I think that the question is whether or not the LUF response *replaces* the original URI, or rather *amends* it with the additional information.

It's also related to the question what data is fed into the LRF? Is the only data fed into that function the response data from the LUF, or is it both the LUF response plus the original URI, eg.:

 tel:+19195551234

With the "domain only" LUF response alone, the LRF could just return a "generic" SF address that requires additional information to properly route the session:

Therefore, it seems to us cleaner when the LUF returns a full AoR. It would still fit the definition of "determining the target domain", it just "copies" certain information from the input data to the output data.

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

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 24 Feb 2010 21:41:26 -0600

Alex,

While I like your idea that the LUF should expand the tel URI to create
the sip URI by adding the domain,
it seemed ambiguous what you want the LRF was to return in that case.

I would prefer that the LRF use the domain to return a Route as you
showed, and keep the distinction between the ultimate target and the
next-hop route as distinct identities, where the LRF result populates a
Route header.

Other thoughts welcome.

Thanks,
Mike Hammer

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Alexander Mayrhofer
> Sent: Wednesday, February 24, 2010 11:28 AM
> To: [email-masked]

---

From: David Schwartz <[email-masked]>
Date: Thu, 25 Feb 2010 13:56:30 +0200

So this issue seems to have plagued us since the inception of SPEERMINT and unfortunately, I see no end in sight.

When attempting to connect to a remote entity using e.164 numbers over IP the 3 (I left out identity mapping) basic questions are:
1. What is the identity of the remote side SP --> output can be an AOR
2. What is the remote side target --> output should be a target
3. How do I get there (LRF)

#1 takes the e.164 number and returns an identity (possibly an AOR)
#2 takes the identity/AOR and returns a target
#3 takes that target and figures out how to get there

Unfortunately, #2 and #3 have been grouped resulting in the confusion that prompted Alex's question regarding "the left side of the @ sign". It is perfectly legitimate to return a SPID in response to #1.

BTW - #2 may be done via some private mechanism (e.g. mapping SPID to target).

David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Wednesday, February 24, 2010 8:12 PM
To: 'Alexander Mayrhofer'; [email-masked]
Subject: Re: [Speermint] Clarification sought about LUF response data.

Alex,

Regards,

Daryl 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Wednesday, February 24, 2010 9:28 AM
To: [email-masked]
Subject: [Speermint] Clarification sought about LUF response data.

rather than

 tel:+19195551234

Alex