Subject: [Sipping] Associating SIP sessions with PSTN calls

From: "Michael O'Doherty" <[email-masked]>
Date: Wed, 18 Sep 2002 16:43:55 +0100

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-association-
01.txt

---

From: [email-masked]
Date: Wed, 18 Sep 2002 13:34:51 -0400

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,

We'd be interested to see if anyone has any comments, in particular if
there are any options we missed.

Cheers,

Mick.

http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-number-association-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

---

From: [email-masked]
Date: Wed, 18 Sep 2002 14:27:08 -0400

Isn't this an application issue as opposed to one that is germane to the
SIP protocol. Option 4, is really a description of a portion of an
application architecture. The determination of the semantics of preferences
for ca routing is really an application issue and not strictly part of the
protocol.
Thanks

Tom Gray

"Michael O'Doherty" <[email-masked]> on 09/18/2002 02:16:13 PM

To:   "[email-masked]'" <[email-masked]>
cc:   "[email-masked]'" <[email-masked]>
Subject:  RE: [Sipping] Associating SIP sessions with PSTN calls

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]]
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

Hi,

Cheers,

Mick.

---

From: "Michael O'Doherty" <[email-masked]>
Date: Wed, 18 Sep 2002 19:43:17 +0100

In general, yes, I think it is, or at least simply an example of a
particular type of use of the SIP protocol - part of the reason to raise it
is to confirm this or to see if anybody has any other ideas for alternative
approaches or enhancements which might have some protocol impact.

The point about being able to make routing decisions based on the media
service is maybe more of a protocol issue, however - I don't think this is
possible right now, and it seems generally useful, so it might be worth
looking at it form a protocol point of view.

Cheers,

Mick. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 18 September 2002 19:27
To: O'Doherty, Michael [MDN05:MD01:EXCH]
Cc: [email-masked]'; [email-masked]'
Subject: RE: [Sipping] Associating SIP sessions with PSTN calls

Tom Gray

Tom,

Comments ?

Cheers,

Mick.

-----Original Message-----
From: [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

Hi,

Cheers,

Mick.

---

From: [email-masked]
Date: Thu, 19 Sep 2002 08:47:56 -0400

Hi

SIP solves this sort of problem with the CPL application server attached to
the proxy. I still think that you are describing an application
architecture that is distinct from the standard SIP architecture. There is
of course nothing wrong with that but the solutions that you are looking
for will not be part of standard SIP. To repeat, you will have to examine
how CPL accomplishes something similar to what you are trying to do and
then modify the basic SIP architecture to accomplish it.

Thanks

Tom Gray

"Michael O'Doherty" <[email-masked]>@ietf.org on 09/19/2002
06:16:05 AM

To:   "'David R. Oran'" <[email-masked]>, "[email-masked]'"
      <[email-masked]>
cc:   "[email-masked]'" <[email-masked]>
Subject:  RE: [Sipping] Associating SIP sessions with PSTN calls

David,

I can see how we could use caller prefs to ensure that a call to a SIP
device associated with a PSTN call arrived at the right place (although in
this case we don't really need to do this) but I am not sure we can use the
approach to stop a SIP voice session call from some other user (who won't
have set any caller prefs and who will have used the same e.164 number to
address the SIP invite) reaching that same SIP device.

It is the same sort of concept but we want the callee to call the shots in
this scenario.

>> 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
>You don't. This is what caller prefs is for, right?

---

From: [email-masked]
Date: Thu, 19 Sep 2002 12:34:10 -0400

Hi

Perhaps I am misinterpreting your draft but I see in it an application
being described that differs from the standard SIP model. As I interpret
the draft, you seem to be describing an application which utilises
parallel PSTN and IP networks. The callee can indicate somehow that he
wishes to have certain calls be serviced exclusively by the PSTN and others
by the IP network. In the draft this is based on media type (codec type)
or perhaps more accurately modality (voice, fax etc). This is not the
standard SIP architecture or at least it is not the standard SIP
architecture unless it is arranged in a very specific way. ENUM (to locate
an LDAP server containing callee preferences) or even perhaps DNS are the
services that you will want to be applied to the architecture that you are
describing, assuming of course that I am not misinterpreting your intent..
The caller client using he extracted callee preferences would then select
the appropriate network and signalling protocol (DTMF, SIP, H.323, ...)This
is not the standard SIP VoIP architecture with proxies.

Thanks

Tom Gray

11:29:06 AM

To:   "[email-masked]'" <[email-masked]>
cc:   "'David R. Oran'" <[email-masked]>, "[email-masked]'"
      <[email-masked]>
Subject:  RE: [Sipping] Associating SIP sessions with PSTN calls

Tom,

Again, I think the CPL application server would have to obey the same rule
as the proxy and not look at the body of the message (or is this not a rule
- still can't find it in the spec??).

This is the part which was highlighted as maybe a more general (i.e. non
application specific) issue - should a SIP server be able to make routing
decisions based on the media service requested in the body ?

Also, for this particular application, if the callee wants the SIP to PSTN
breakout to be at the caller's end of the call it seems cleaner to use an
ENUM or CLI lookup domain type solution (the latter being the one we went
for as ENUM as it stands did not seem to handle this).

Cheers,

Mick.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 19 September 2002 13:48
To: O'Doherty, Michael [MDN05:MD01:EXCH]
Cc: 'David R. Oran'; [email-masked]'; [email-masked]'
Subject: RE: [Sipping] Associating SIP sessions with PSTN calls

Hi

Thanks

Tom Gray

David,

options

---

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,
	>>
	>>calls (even from SIP phones) and their SIP device for other media
	>>sessions (like PSTN associated sessions).
	>>
	>>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.
	>>
	>>
	>>From: [email-masked]
	>>[<mailto:[email-masked]>mailto:[email-masked]]
	
>><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

	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: "Stastny Richard" <[email-masked]>
Date: Fri, 20 Sep 2002 09:44:26 +0200

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

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
	>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,
	>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
	>questionable uses for ENUM that simply don't work.  I would encourage you

	Yes please  .. as your friendly neighborhood ENUM WG -co chair I encourage
	this.

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

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

---

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

---

From: [email-masked]
Date: Wed, 25 Sep 2002 08:16:58 -0400

At the risk and probable certainty of belabouring this far  beyond what
everyone else would like, I would like to ask the question of just what in
SIP is concerned with an applicaion like this.. The 'callee' somehow
indicates  that he would like calls to his voice device to traverse the
PSTN for as much length as possible with the strong preference that the
complete path would be in the PSTN.  Obviously a protocol, like ENUM, could
be used to determine this preference beforehand (by accessing some
preference server) and the caller could then honour the callee preference
by making the call on the PSTN or breaking out of the IP network at the
nearest gateway. I just don't see that this is something that is of much
concern to SIP or any other IP telephony protocol.

Tom Gray

Jonathan Rosenberg <[email-masked]>@ietf.org on 09/25/2002
02:48:04 AM

To:   [email-masked]
cc:   "David R. Oran" <[email-masked]>, "Michael O'Doherty"
      <[email-masked]>, "'Alan Johnston'"
      <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject:  Re: [Sipping] Associating SIP sessions with PSTN calls

[email-masked] wrote:
> Isn't  the issue here concerned with 'callee' preferences.

Yes, I believe it is largely an issue of callee preferences.

In the defining
> example in the draft, a user wishes to receive voice calls on his PSTN
> device and wishes that the call would travel over the PSTN. It should
break
> out of any IP network as soon as possible and possibly never travel over
> it. At least that is my reading of the draft, although I may be
completely
> out to lunch here.. It highlights the issue of honouring callee
preferences
> during call set up. It is the traversal of the PSTN network rather than
the
> use of the PSTN device which strikes me as something that ii not part of
> the current SIP structure

I don't really see anything in the draft that is "not part of the SIP
structure". We've always supported flexible call routing, which is what
this is.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Michael O'Doherty" <[email-masked]>
Date: Wed, 25 Sep 2002 13:42:07 +0100

Tom,

As you mentioned before I think that most of the discussion is around an
application of SIP rather than something that needs to be standardized. The
purpose of raising it in the Sipping group was to make sure that we weren't
missing something and to understand the alternatives a bit better (which
continues on the ENUM list).

The one thing that I think maybe is a SIP standards issue is the discussion
around a callee wanting to route calls differently based on the media
type(s) in the call.

Not being able to do this (whether it is explicitly not allowed in the spec
or because the body will be end to end encrypted) does limit the services
that can be developed in SIP servers in the network.

Something along the lines of Jonathan's media policy mechanism's draft or
perhaps allowing two SDP's in the body, one encrypted and one available for
anyone who wants to look at it, or maybe even just encrypting certain parts
of the SDP seems to me like it would be useful, and maybe worth discussing
further.

Cheers,

Mick.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 25 September 2002 13:17
To: Jonathan Rosenberg
Cc: [email-masked]; David R. Oran; O'Doherty, Michael
[MDN05:MD01:EXCH]; 'Alan Johnston'; [email-masked]'
Subject: Re: [Sipping] Associating SIP sessions with PSTN calls

Tom Gray

To:   [email-masked]

In the defining
break
completely
preferences
the

-Jonathan R.