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

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 +13035551212@ssp.example.com.  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: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Alexander Mayrhofer
Sent: Wednesday, February 24, 2010 9:28 AM
To: speermint@ietf.org
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 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:+19195551234@voip.example.com

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:9195551234@192.168.2.12: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:sbc@192.168.2.12: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
_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www.ietf.org/mailman/listinfo/speermint