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

From: "Michael O'Doherty" <[email-masked]>
Date: Thu, 19 Sep 2002 11:20:27 +0100

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

- 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.
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. Or
they might just want the caller to incur any costs associated with the SIP
to PSTN breakout ...).

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-associatio
n-01.txt>http://ties.itu.int/~watsonm/draft-odoherty-sipping-pstn-number-ass
ociation-01.txt

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 19 Sep 2002 11:41:34 -0400

--On Thursday, September 19, 2002 11:20 AM +0100 Michael O'Doherty 
<[email-masked]> wrote:

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 22 Sep 2002 22:41:08 -0400

inline.

> Why, pray tell? What is missing from the SIP headers that is needed?

If the caller expresses a preference expicitly, then yes, the headers 
say what is required. For example, if a caller explicitly says "route 
this call to a UA that supports video":

Accept-Contact: *;media="video"

The problem that Michael is talking about is where the caller does not 
explicitly state this preference; its a normal SIP invite, whose body is 
SDP and happens to have a video stream in it. The only way for the proxy 
to know this at the moment is to look at the body. In fact, my current 
working copy of caller prefs has added support for an implicit 
preference for media types by looking at the body. That is, it would 
construct the above caller prefs header, and use it as if it were in the 
message, if the SDP indicates video. This implicit preference is at MAY 
strength because SMIME may make it impossible to do.

It would always be possible to do with my media policy mechanism, by the 
way:
http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt

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

Yup. Breaks midcom too. Thats why I wrote the above draft.

> routing issue dealt with by gateway routing protocols like TRIP.

True; but I think Michael's point is that the policy which guides these 
routing policies exists within the callee's domain.

If you want the callers domain to make such policy decisions, then you 
can redirect rather than proxy.

Generally speaking, It is well within the bounds of a proxy to route a 
call to one place or another based on any information it likes. That 
includes looking at the bodies, and other such things. A CPL script 
could be used to guide this logic, or a servlet, or whatever. The caller 
prefs spec will allow a proxy to know the callers preference, and to 
know information about registered contacts to help guide its routing 
decision.

This, of course, leads to one of the big differences between a SIP-based 
approach and an enum-based approach. If the routing decision is made by 
a proxy in the callee's domain, the callee (who ultimately cares to 
which device the call is routed), can make this decision based on the 
time of day, the identity of the caller, or the temperature in Zimbabwe. 
Since enum is a directory service, that kind of logic can't be there. 
This is what Dave is alluding to when he was referring to enum as a 
directory service, not a routing service.

-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