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

From: "Michael O'Doherty" <[email-masked]>
Date: Fri, 20 Sep 2002 11:37:03 +0100

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.

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

Thank you Richard for forwarding this discussion to the ENUM list.
 
As you stated below, the topic has already been discussed (;-) sigh) at
the ENUM list. There is also existing my draft-stastny-enum-scenarios-00.txt
which beside other issues dealing with this problem.
 
Furthermore I want to point out that exactly the discribed scenario is
one of the main topics of our ENUM-trials, especially the VISIONng
ENUM-trial dealing with +87810 UPT. In the case of personal numbers
the calls are routed as described below on the PSTN in the normal
way to a gateway. In addition, a GW (either SIP or H323) exists on the
Internet. The ENUM entry contains a pointer to this gateway. Anybody 
querying ENUM may directly route the call to this gateway and the call
is terminating in the same way as if it would come from the PSTN. The 
termination could either be on an IP-based client or on the PSTN or a 
mobile terminal, if forwarded. Of course the same may happen for any
normal termination on the PSTN, ported or not, if a GW aka point-of-
interconnect (PoI) exists on the Internet, and this PoI is annonced e.g. via
ENUM.
 
In the draft-brandner-enumservices-compendium-00.txt the ivoice service
is introduced "as an convenient way of indicating that the resource
indicated
by the associated URI is connected to an IP network ..."
 
The main discussion up to now is, if in addition to User-ENUM a second
tree called Infrastructure ENUM is existing, because not all numbers of
a given range may exist in user ENUM because of the opt-in principle and
the potential problems caused by a clash of responsibilities in the Tier 2.
This second tree is also proposed in draft-ietf-enum-e164-gstn-np-05.txt
 
Anyway, I am currently working on an I-D putting together the above
mentioned documents, draft-yu-sip-np, draft-yu-tel-url and
draft-brandner-tel-svc
for a consistent application of ENUM on NP, Freephone and other routing
issues.
 
Finally it should be possible to announce the destination (GW, PoI, PSTN
route) of 
ANY phone number in ENUM, to by queried by the origination (user and/or
network)
directly. 
 
HEALTH WARNING: If you are not aware already, this will obsolete carriers
and 
transit networksand allow global number portability for any E.164 number,
even for
geographic numbers.
 
And I fully agree to the statement below from Alan, that this is the real
application for ENUM: a globally available, scaleable, performant
IN-Service.
 
regards
Richard Stastny

	-----Ursprüngliche Nachricht----- 
	Von: Richard Shockey [mailto:[email-masked]] 
	Gesendet: Do 19.09.2002 19:28 
	An: Alan Johnston; Michael O'Doherty; [email-masked]' 
	Cc: [email-masked]'; [email-masked] 
	Betreff: [Enum] RE: [Sipping] Associating SIP sessions with PSTN
calls

	At 01:58 PM 9/18/2002 -0500, Alan Johnston wrote:
	>Michael,
	>
	>Tom is right - ENUM is the right solution to this.  Here is how it
could work:
	>
	>If the PSTN number is dialed in the PSTN, it routes as normally and
rings
	>the user's PSTN phone, which is what you want.
	>
	>If the PSTN number is dialed in a SIP network which does not query
ENUM,
	>the call will be routed to a PSTN gateway and ring the user's PSTN
phone,
	>which again is a success.
	>
	>If the PSTN number is dialed in a SIP network that does query ENUM,
it
	>returns a SIP URI for the endpoint.  An INVITE is then sent to the
proxy
	>in the domain of the SIP URI, which presumably is the service
provider for
	>the user.  The proxy knows that this user wishes to receive calls
on their
	>PSTN phone (for some reason), so it routes the call to a PSTN
gateway and
	>rings the user's phone.
	>
	>Any SIP requests which are for other media sessions or any other
purpose
	>are routed using ENUM to the proxy, which forwards them to the SIP
User
	>Agent, which establishes the associated session you are after
(whatever
	>that is).
	>
	>You are right, however, in noting that this sort of use is not
described
	>in any of the ENUM documents - they mainly describe a whole set of
	>questionable uses for ENUM that simply don't work.  I would
encourage you
	>to bring this up on the ENUM list, as this is exactly what ENUM was
	>designed to do.

	Yes please  .. as your friendly neighborhood ENUM WG -co chair I
encourage
	this.
	
	I will cross post the document to my list ASAP.
	
	We've been over a lot of this ground already.

	>Thanks,
	>Alan Johnston
	>sip:[email-masked]
	>
	>
	>At 07:16 PM 9/18/2002 +0100, Michael O'Doherty wrote:
	>
	>>Tom,
	>>
	>>The first option in the draft below looks at ENUM.
	>>
	>>The main problem is if the user wants to use their PSTN phone for
voice
	>>calls (even from SIP phones) and their SIP device for other media
	>>sessions (like PSTN associated sessions).
	>>
	>>How do we indicate with an ENUM response that voice calls should
go to
	>>the PSTN number and other media/mixed media calls to a SIP device
(one
	>>suggestion here was that if ENUM returns a tel URL as one of the
options
	>>for routing then that option MUST be used if the call is a voice
call) ?
	>>
	>>We couldn't see any nice clean way to do this with ENUM as it
stands
	>>today - option 4 in the draft (using a well know domain to do the
CLI
	>>lookup) just seemed to be less messy and more obvious.
	>>
	>>Comments ?
	>>
	>>Cheers,
	>>
	>>Mick.
	>>
	>>
	>>-----Original Message-----
	>>From: [email-masked]
	>>[<mailto:[email-masked]>mailto:[email-masked]]
	>>Sent: 18 September 2002 18:35
	>>To: O'Doherty, Michael [MDN05:MD01:EXCH]
	>>Cc: [email-masked]'
	>>Subject: Re: [Sipping] Associating SIP sessions with PSTN calls
	>>
	>>
	>>
	>>Why can't the answer to this be ENUM?
	>>
	>>
	>>
	>>
	>>
	>>"Michael O'Doherty" <[email-masked]>@ietf.org on
09/18/2002
	>>11:43:55 AM
	>>
	>>Sent by:  [email-masked]
	>>
	>>To:   "[email-masked]'" <[email-masked]>
	>>cc:
	>>Subject:  [Sipping] Associating SIP sessions with PSTN calls
	>>
	>>
	>>
	>>Hi,
	>>
	>>The draft below describes a number of schemes to allow a SIP
session be
	>>associated with a PSTN call, plus the authors choice of the best
approach
	>>from the options briefly described.
	>>
	>>We'd be interested to see if anyone has any comments, in
particular if
	>>there are any options we missed.
	>>
	>>Additionally, looking at this problem domain threw up a more
general
	>>requirement also:
	>>
	>>  - the ability to route a SIP request differently depending on
the media
	>>service that the request is requesting
	>>
	>>Do people feel this is a valid requirement in a  SIP networks and
if so has
	>>anybody any thoughts on how it might be addressed ?
	>>
	>>Cheers,
	>>
	>>Mick.
	>>
	>>The draft can be retrieved form the link below until it shows up
in the
	>>archives:
	
>><http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-number-associati
on-01.txt>http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-number-as
sociation-01.txt
	>>
	>>
	>
	>_______________________________________________
	>Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
	>This list is for NEW development of the application of SIP
	>Use [email-masked] for questions on current sip
	>Use [email-masked] for new developments of core SIP

	Richard Shockey, Senior Manager, Strategic Technology Initiatives
	NeuStar Inc.
	46000 Center Oak Plaza   Bldg 10    Sterling, VA  20166
	Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
	<mailto:[email-masked]> or <mailto:[email-masked]>
	<http://shockey.us > ; <http://www.neustar.biz> ;
<http://www.enum.org>
	<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	
	_______________________________________________
	enum mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/enum

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 20 Sep 2002 15:39:47 +0100

At 11:37 am +0100 20/9/02, Michael O'Doherty wrote:
>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
>
>- the caller uses the ENUM lookup to return the callee's SIP URI as 
>first choice and a tel url as second choice
>- 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)
>

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: Richard Shockey <[email-masked]>
Date: Fri, 20 Sep 2002 11:01:36 -0400

At
>'!^.*$!sip:[email-masked]'  .

or just NAPTR 10 10 'u' 'E2U+sip' '!^.*$!sip:[email-masked]'  .

Larry you knew I was going to point this out. :-)

>T

<http://shockey.us > ; <http://www.neustar.biz> ; <http://www.enum.org>