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

[David Schwartz <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Daryl Malas
Sent: Wednesday, February 24, 2010 8:12 PM
To: 'Alexander Mayrhofer'; [e-mail]
Subject: Re: [Speermint] Clarification sought about LUF response data.

Alex,

The purpose of the definition is to say for a given request, [phone], the LUF determines the target domain, ssp.example.com; which, results in [e-mail].  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: [e-mail] [mailto:[e-mail]] On Behalf Of Alexander Mayrhofer
Sent: Wednesday, February 24, 2010 9:28 AM
To: [e-mail]
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:[phone] -> LUF -> sip:[e-mail]

rather than

  tel:[phone] -> 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:[phone]
   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
[e-mail]
https://www.ietf.org/mailman/listinfo/speermint
_______________________________________________
Speermint mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/speermint