Subject: RE: [Enum] Associating SIP sessions with PSTN calls

From: "Michael O'Doherty" <[email-masked]>
Date: Fri, 20 Sep 2002 18:08:22 +0100

Lawrence, All,

Firstly a comment - in trying to understand this answer I was lucky enough
to stumble across the ENUM service analysis draft which explained a lot of
the thinking - it would be a big help if this was on the ENUN Charter site !

A couple of questions (if any of the questions don't make sense, you can
take it that I am a bit confused at this stage !):

The reason the second record below results in the caller firing up their
local dialer program (rather than doing another ENUM lookup) is because of
the comment in the ENUM RFC saying that the client is responsible for loop
detection - is this right or it there some more explicit reason ?

Using the 'E2U' parameter in the service field to indicate that this record
belongs to the ENUM system, does not match the definition of this field in
the NAPTR RFC and is quite confusing - should this field not simply list
services available down this rewrite path and optionally the protocol that
is used to speak to the services ?

The NAPTR RFC refers to 'protocols' and 'rs' in the service field - the
service analysis draft seem to refer to URI schemes. Are we assuming that
'protocol' in the former mapps to 'URI scheme in the latter ?

I think I understood that the definition of the services (or 'rs' fields) is
to be done on a per protocol basis, plus some general ones constructed by
using the scheme URI and a general service type - if so is this not tying
the service to a particular protocol ? The example below seems to do the
opposite (i.e. not tie the service to a protocol) with the use of 'voice'
and 'ivoice' services ?

If the URI scheme is to be used as the start of the service name, would it
be a good idea to have some sort of delimiter before the rest of the service
name - I think this would make it a lot clearer.

What does the term 'enumservices' mean - these services are not really
enumservices, they are services which happen to be reached using an ENUM
lookup, or am I not understanding this correctly ?

I'll stop there as other questions I have my be addressed by the answers to
the above (plus it is late here ...).

Cheers,

Mick.

-----Original Message-----
From: Lawrence Conroy [mailto:[email-masked]]
Sent: 20 September 2002 15:40
To: O'Doherty, Michael [MDN05:MD01:EXCH]; 'Stastny Richard'; 'Richard
Shockey'; 'Alan Johnston'; [email-masked]'
Cc: [email-masked]
Subject: RE: [Enum] Associating SIP sessions with PSTN calls

At 11:37 am +0100 20/9/02, Michael O'Doherty wrote:
>All,
>
>I am confused here so I want to make sure I am not missing something.
>
>At it's simplest the requirement is for a callee to be able to 
>ensure that if someone sets up a  SIP call to them using the 
>callee's PSTN phone number as a SIP address (as a FQDN as outlined 
>in ENUM) that the call be routed as follows:
>
>- If the call is a voice call the call it should be routed to the 
>users PSTN phone
>
>- If the call is a non-voice (or mixed media) call it should be 
>routed to the users SIP device
>
>As far as I can see the best way to do this with ENUM is:
>
>- the caller uses the ENUM lookup to return the callee's SIP URI as 
>first choice and a tel url as second choice
>- the call is routed to the callee's SIP device
>- the SIP device sees it is a voice call and redirects the call to a 
>tel URL with the users PSTN number (or just fails the call and the 
>second choice from the ENUM lookup is used)
>
>- the caller uses the tel URL to break out to the PSTN network
>
>Is there another/better way to achieve the same thing using ENUM ?
>
>Cheers,
>
>Mick.
>

Hi Mick, folks,
   If I understand the above, then "It just works (tm)".

I think that the Callee (Registrant) puts the following into ENUM (DNS)
space:

$ORIGIN 6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa.
.  NAPTR 10 10 'u' 'E2U+ivoice+video+srs' 
'!^.*$!sip:[email-masked]'  .
.  NAPTR 10 10 'u' 'E2U+voice' '!^.*$!tel:+441794833666'  .

Both of these NAPTRs "fit" - there is no second or first choice here as
they both have the same order and preference values. No worries, as ...

The Caller (or their agent) does an ENUM lookup.
In ENUM queries, the caller registers an interest in some enumservice(s)
and this is used by their local ENUM client 'engine' to filter out the
NAPTRs that are appropriate. (The caller could pass these "interests"
as parameters when running their ENUM client).

If the caller is interested in a voice call, then the second of these will
match, whilst the first will be less preferable, but will act as a fallback.

If the caller is interested in the video call, then the first will match.

Likewise, if the caller prefers to make a call using VoIP then they would
have registered an interest in ivoice as well. Again, the first one matches.

If the caller is happy to leave a "service resolution service" to deal
with the negotiations (basically, leave it to SIP), then again the first
record will match.

Once the record has been chosen, it's up to the caller's client to execute
an action based on the generated URI in the record they have selected.

In the first one has been selected, then I guess the result is to fire
up their trusty SIP UAC.

If the second one has been selected, then (for some) the result is firing
up their local dialler program (and this will dial out over the PSTN).

Thus, where's the problem?

all the best,
    Lawrenece
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 21 Sep 2002 11:15:39 +0100

Hi Mick, folks,
   Yup - I can understand the confusion (you'll fit right in to this group :).

----
For examples of potential enumservices, Rudi Brandner has produced a draft
that gives descriptions for SOME of these:
  <http://www.ietf.org/internet-drafts/draft-brandner-enumservices-compendium-00.txt>
This obsoletes/subsumes the earlier "categorical enumservices" draft.

There's also a draft describing an ifax service:
  <http://www.ietf.org/internet-drafts/draft-toyoda-enum-faxservice-00.txt>

These matches the latest update to the ENUM RFC:
  <http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-01.txt>.

I'm promised that there will be an updated 'sip' enumservice draft 
out real soon now,
and some VPIM-style enumservices.

----
Good question as to why these and others are not linked from the charter page.
Our esteemed co-chairs can clarify, but I think that, strictly, the charter
focuses on the "framework" rather than the specific enumservice definitions.

Thus 2916bis must be there, but the sip enumservice document isn't; nor is
the enumservice-compendium (nor draft-stastny-enum-scenarios-00.txt?).

----
The compendium draft is intended to fit with the syntax of rfc2916bis-01,
as does the faxservice draft.
As the service field syntax has changed somewhat from the original RFC2916,
it makes the older drafts obsolete :-\ Notably, Rudi's 'tel' enumservice
draft no longer fits with ENUM syntax (nor does the sip enumservice draft,
I think). Most other drafts are suspect as well - hey ho - that's the price
of progress.

----
As highlighted in rfc2916bis-01, the 'protocol' sub-field need not define
the IP protocol to be used with the URI. Nor does it merely duplicate the
URI scheme. The service field of a NAPTR describes the services with which
this record may be used. Thus, your guess that an enumservice is actually
a service that can be realised using the NAPTR retrieved using an ENUM look
up is spot on.

To paraphrase Humpty Dumpty, "a service means what I want it to mean".
See 2.4.2.1 of RFC2916bis-01 for the official word.

Each enumservice definition document should have a description of the kind
of behaviour and expected result from executing the 'service', so you need
to look there. (See section 3 of rfc2916bis for details of what these drafts
should define). The definition also includes the URI schemes with which this
enumservice is associated, and what is expected to happen when a particular
URI scheme is encountered with a given enumservice.
Note that this is "harris about apex" relative to the "choose URI scheme,
then choose service" that you guessed might be happening.
With ENUM, one looks at the service field to see if the NAPTR is interesting,
and THEN looks at the processed URI to execute the service - now, you could
process all of the NAPTRs, look at each of their generated URI schemes, and
then look at the NAPTR service fields, but this is NOT the expected way that
a client would operate.

----
Looping is a whole different issue, so I'll defer this to another posting.

Hope this helps.

all the best,
   Lawrence

At 6:08 pm +0100 20/9/02, Michael O'Doherty wrote:
>Lawrence, All,
>
>Firstly a comment - in trying to understand this answer I was lucky 
>enough to stumble across the ENUM service analysis draft which 
>explained a lot of the thinking - it would be a big help if this was 
>on the ENUN Charter site !
>
>A couple of questions (if any of the questions don't make sense, you 
>can take it that I am a bit confused at this stage !):
>
>The reason the second record below results in the caller firing up 
>their local dialer program (rather than doing another ENUM lookup) 
>is because of the comment in the ENUM RFC saying that the client is 
>responsible for loop detection - is this right or it there some more 
>explicit reason ?
>
>Using the 'E2U' parameter in the service field to indicate that this 
>record belongs to the ENUM system, does not match the definition of 
>this field in the NAPTR RFC and is quite confusing - should this 
>field not simply list services available down this rewrite path and 
>optionally the protocol that is used to speak to the services ?
>
>The NAPTR RFC refers to 'protocols' and 'rs' in the service field - 
>the service analysis draft seem to refer to URI schemes. Are we 
>assuming that 'protocol' in the former mapps to 'URI scheme in the 
>latter ?
>
>I think I understood that the definition of the services (or 'rs' 
>fields) is to be done on a per protocol basis, plus some general 
>ones constructed by using the scheme URI and a general service type 
>- if so is this not tying the service to a particular protocol ? The 
>example below seems to do the opposite (i.e. not tie the service to 
>a protocol) with the use of 'voice' and 'ivoice' services ?
>
>If the URI scheme is to be used as the start of the service name, 
>would it be a good idea to have some sort of delimiter before the 
>rest of the service name - I think this would make it a lot clearer.
>
>What does the term 'enumservices' mean - these services are not 
>really enumservices, they are services which happen to be reached 
>using an ENUM lookup, or am I not understanding this correctly ?
>
>I'll stop there as other questions I have my be addressed by the 
>answers to the above (plus it is late here ...).
  (6PM isn't late :).

In response to my post:

>I think that the Callee (Registrant) puts the following into ENUM (DNS) space:
>
(to which our esteemed co-chair Rich Schockey pointed out that one could
  use the following in place of the first:
  . NAPTR 10 10 'u' E2U+sip' '!^.*$!sip:[email-masked]'  .
)
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.

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