Subject: RE: [Sipping] refer to PSTN

From: "Stastny Richard" <[email-masked]>
Date: Tue, 16 Mar 2004 10:33:59 +0100

Hi Juha,

There is a problem with an indicator forcing a call to the PSTN by
preventing an ENUM lookup
We have discussed this in the IPTEL WG list and I attach the relevant
posting below,
which was an argument between Flemming and me.

The problem is that considering ENUM-only numbers (and not only opt-in),
some numbers may not
terminate on the PSTN in any case.

I came to the conclusion that Flemming is right and we should separate
Number translation and routing

If an indicator is required to force a call to the PSTN, it should be
independent from enum: eg tel:+xxx;pstn

I case of an ENUM-only number the call would in this case end up on IP
via the PSTN.

Richard

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Tuesday, March 16, 2004 9:34 AM
> To: Arunachalam Venkatraman
> Cc: [email-masked]
> Subject: RE: [Sipping] refer to PSTN
> 
> 
> Arunachalam Venkatraman writes:
> 
>  > I suppose you could specify a tel-uri in the Refer-To URI.
> 
> tel uri alone wouldn't solve the problem.  i also need a way 
> to tell that no more enum lookups should be done on the number.
> 
> it turns out that this topic is right now being discussed on 
> iptel mailing list and people are proposing an uri parameter, 
> such as enum=yes/no, for that purpose.
> 
> -- juha

Cross Posting from iptel list:
------------------------------------------------------------------------
--------------------------------------------------------

First, I want to thank Flemming for summarizing the old thread
 
Regarding A and B:

	<snip>
	>> A: it is not necessary to ask ENUM again for this E.164
number, because
	>> I did it already, but if you have some spare time and nothing
to do
	>> else, you
	>> may ask again.
	>> B. You MUST NOT ask ENUM
	<snip>

	>Interesting; I would go for A. I think there is a different
between name
	>resolution and routing with associated routing policy. I think
ENUM only
	>addresses the name resolution part, and that routing and
routing policy
	>should be managed elsewhere. Consequently, I don't think we
should try and
	>use the "enumdi" to influence routing either; just name
resolution.
	
	After thinking some time about this, I have to admit that you
are right.
	 
	I first thought about proposing both solutions e.g enum=yes (A)
and
	enum=no (B) and tried to find arguments, but finally got ahead
of myself,
	and nearly shot myself in the foot ;-)
	 
	To explain my conclusion I try to think loud:
	 
	If ENUM would only be opt-in, case B would make sense. The
reason is that
	in the opt-in case for the first time a number is terminating in
two destination
	networks, the PSTN and the Internet. So also "terminating
network selection" would
	make sense. If on originating user decides to select the
terminating network (e.g.
	the PSTN, there must be a way to convey this information to his
server and from
	there to the next. 
	 
	Reaching this conclusion, I run into a problem:
	 
	We are currently considering also in addition ENUM-only numbers,
which are
	only existing in ENUM and can be routed only via ENUM. Since a
originating
	user may not know which numbers are ENUM-only, a terminating
network selection
	is not possible or may even be dangerous, because ENUM-only
numbers could
	not be routed if enum=no is set.
	 
	Conclusion:
	the "enumdi" is used only in signalling in the same way as the
npdi, it just
	indicates that an ENUM query has already be made. 
	 
	Richard

_______________________________________________
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

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 16 Mar 2004 13:37:05 +0200

> independent from enum: eg tel:+xxx;pstn

this would be fine with me.  is someone writing an internet draft
describing the pstn uri parameter or does someone have a better idea on
how to solve the problem?

-- juha