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

From: Richard Shockey <[email-masked]>
Date: Thu, 19 Sep 2002 13:29:57 -0400

FYI from the sipping list..

>Date: Thu, 19 Sep 2002 11:41:34 -0400
>From: "David R. Oran" <[email-masked]>
>To: "Michael O'Doherty" <[email-masked]>,
>    "'Alan Johnston'" <[email-masked]>,
>    "[email-masked]'" <[email-masked]>
>cc: "[email-masked]'" <[email-masked]>
>Subject: RE: [Sipping] Associating SIP sessions with PSTN calls
>X-Mailer: Mulberry/3.0.0b3 (Win32)
>Sender: [email-masked]
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.0.12
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
>         <mailto:[email-masked]?subject=unsubscribe>
>List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
>         <mailto:[email-masked]?subject=subscribe>
>
>--On Thursday, September 19, 2002 11:20 AM +0100 Michael O'Doherty 
><[email-masked]> wrote:
>
>>
>>Alan,
>>
>>Couple of comments on this approach:
>>
>>- firstly, I think this would mean that the proxy would have to look at
>>the body to decide what type of call it was handling.
>Why, pray tell? What is missing from the SIP headers that is needed?
>
>>I did'nt think
>>proxy's were allowed to do this (although I admit I could'nt see anything
>>in a quick span of the proxy behaviour scetion of the RFC).
>Some proxies look at bodies. They'd better not depend on it though, 
>because once end-to-end SMIME shows up all they'll see is ciphertext.
>
>>- assuming we get around the above point somehow, this solution means
>>that the callee is effectively choosing the point where the call breaks
>>out form the SIP network to the PSTN.
>Not necessarily. All the callee's proxy is deciding is whether the call 
>goes to  a contact (or contacts) on the IP network, or to a contact (or 
>contacts) on the PSTN. Where the call actually exits to the PSTN is a 
>routing issue dealt with by gateway routing protocols like TRIP.
>
>>In some cases it may be more efficient for the caller to decide the
>>breakout point (if the callee is located someplace where they can't get
>>good enough QoS for voice but it is fine for whiteboarding applications
>>etc and they want to force the caller to break out to the PSTN as soon as
>>possible.
>You're mixing signaling and media here. It doesn't matter one whit if the 
>SIP signaling goes half-way around the world as long as the right exit 
>gateway is selected based on where the call came in (if it came in from 
>the PSTN) and where it's going (if it exits to the PSTN). Again, this is 
>part of routing, not part of ENUM directories or proxy forking policy.
>
>>Or they might just want the caller to incur any costs
>>associated with the SIP to PSTN breakout ...).
>Billing is a separate thorny issue. One thing I'm pretty confident of is 
>that ENUM is not the place to be putting policy about billing.
>
>One meta-comment I will make is that the issues you raise are all related 
>to ROUTING - i.e. the selection of the path between A&B rather than 
>whether A talks to B or C, or D. Routing needs routing protocols (e.g 
>TRIP, TGRP). ENUM is a *directory* scheme, which means it depends on the 
>destination only, not the source, and hence cannot do much of what is 
>needed to solve the routing problem.
>
>Dave.
>
>>Cheers,
>>
>>Mick.
>>
>>-----Original Message-----
>>From: Alan Johnston [mailto:[email-masked]]
>>Sent: 18 September 2002 19:59
>>To: O'Doherty, Michael [MDN05:MD01:EXCH]; [email-masked]'
>>Cc: [email-masked]'
>>Subject: RE: [Sipping] Associating SIP sessions with PSTN calls
>>
>>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.
>>
>>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-associa>> 
>>>tion-01.txt>http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-num
>>>ber-association-01.txt
>>
>>>
>>>
>
>------------------------
>David R. Oran
>Cisco Systems
>7 Ladyslipper Lane
>Acton, MA 01720
>Office: +1 978 264 2048
>VoIP: +1 408 571 4576
>Email: [email-masked]
>_______________________________________________
>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: Richard Shockey <[email-masked]>
Date: Thu, 19 Sep 2002 13:28:49 -0400

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:
>
>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.
>

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.

>>associated with a PSTN call, plus the authors choice of the best approach
>>from the options briefly described.
>>
>>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.
>>
>><http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-number-association-01.txt>http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-number-association-01.txt 
>>
>>
>

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 20 Sep 2002 09:44:26 +0200

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

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 20 Sep 2002 10:31:30 +0200

Add-on after reading (quick scan) the O'Doherty draft,
which is an additional function, having two separate calls in parallel,
(funny how new ideas pop up constantly with ENUM).
Question: why not use the second call for voice also and
drop the first?
 
Anyway, as one likes: thats exactly what the enumservices are for. With 
enumservices voice and ivoice you MAY give different routings for PSTN 
and IP. If one has a PSTN call esatblished, he may also use the enumservice
video specificly selected for the second call.
 
Also the approach described below from Alan works if one uses srs and let sip negotiate.
 
I do not see any problems with the current set of proposals set out for enumservices.
 
regards
Richard