Hi Igor,
I've attached an additional example of a scenario that you've requested.
Please see other responses inline.
thanks for your help,
Bryan
Igor Slepchin wrote:
> > -----Original Message-----
> > From: Bryan Byerly [mailto:[EMAIL PROTECTED]]
> >
> > As I presented at the December 2000 IETF, the I-D is
> > motivated by several
> > PSTN/SIP internetworking scenarios including:
>
> I'd like to see what internetworking scenarios don't work without it.
I've attached one such example.
> > Multiple diversions.
>
> Hmm, these are not really supported by PSTN. Just as your draft says, the
> only information available in ISDN parameters are the called party and the
> redirecting number. Nowhere does PSTN remember all the previous redirections
> like suggested by the draft.
Actually, as the Diversion I-D points out, most ISUP and ISDN variants support
up to 2 redirecting numbers. Could you point out the part of the Diversion
I-D that led you to believe there could be only one? We'd need to clarify that
section.
> > Diverting a call to an E.164 service.
>
> What services is Diversion header required for? There are lots of obscure
> parameters in PSTN signaling; replicating all of them in SIP does not sound
> like a very good idea and is not necessary for internetworking.
The Diversion I-D is focused on answering 2 questions for the (ultimately)
called user agent:
>From whom was the call diverted?
Why was the call diverted?
Implementations of services such as voicemail and night service frequently
require this information.
> > Configuration issues (moving policy configuration to edges (UAs))
> >
> > An ultimately called UAS can use the Diversion headers to
> > implement a local
> > policy for his particular service. For example, to answer
> > the question:
> > Into which voice mailbox should a message be placed? It's
> > important to
> > understand that this is a policy decision; and as such should be
> > configurable at the ultimate edge of the voice network (i.e.
> > move the smarts
> > to the edges). The examples in section 9 do cover some of
> > these issues.
>
> I find examples in section 9 rather farfetched. No company is ever going to
> have SIP addresses that look like sip:[EMAIL PROTECTED] (when was the last
> time you saw a real company with an email account at aol.com?)
> Realistically, the night service calls you mentioned will be redirected to
> something like [EMAIL PROTECTED] or [EMAIL PROTECTED]
The example shows translation of a generic keyword (pizza) into a specific URL
as determined by the policy of the "carrier". Today's web brower
"carriers" already exhibit this type of behavior today. Try typing "pizza" in
your web browser... I wouldn't be surprised if the topmost hits weren't
somehow compensating the web browser "carrier". I'd imagine that tomorrow's
VoIP carriers could base some business models off of this idea.
Again, please also see the attached example below. Perhaps it will seem more
realistic.
The Diversion header is merely providing supplementary information that cannot
always be found in any other parts of the SIP PDU. Implementors of some
services (including voicemail and nightservice) need a consistent
(standardized) mechanism to retrieve this supplementary information so that
they can apply policy decisions to it to affect their service logic. The
Diversion header provides such a mechanism and does so without creating a
configuration burden on system administrators of intermediate gateway/routing
nodes.
thanks again for your help,
Bryan
Bryan J. Byerly
[EMAIL PROTECTED]
In the following ladder diagram, a call is placed from the PSTN to 5551234 which hangs
off of the 555xxxx PBX. The Call Forward No Answer (CFNA) timer expires in the PBX,
and
the PBX diverts the call to the user's admin/secretary at 5551001. The secretary's
phone
is busy, so the PBX diverts the call through the local PSTN/SIP gateway and SIP proxy
to the voicemail service with which the enterprise has contracted, in this case a
SIP voicemail service. The SIP proxy performs an (ENUM) lookup of 9231000 which
resolves to 3.3.3.3.
When the call reaches the voicemail server, the message may be deposited into a voice
mailbox
for 5551234, 5551000, or both depending on the policy configured at the voicemail
service.
In addition, in practice one would normally encounter scenarios where the SIP proxy is
owned
by a carrier and the voicemail server by a third party. In this example, usage of the
Diversion
header allows voicemail service policy to be changed (by the voicemail provider)
without requiring
changes in the carrier's equipment.
(555xxxx) (9231000)
(1.1.1.1) (2.2.2.2) (3.3.3.3)
PSTN PBX GW SIP Proxy SIP voicemail server
| | | | |
|--Setup---------->| | | |
| called:5551234 | | | |
| | | | |
|<-Call Proceeding-| | | |
| | | | |
|<-Alerting--------| | | |
| | | | |
| CFNA timer expires | | |
| | | | |
| ----| | | |
| / Call presented to 5551001 (admin) |
| \ | | | |
| ---->| | | |
| busy | | |
| | | | |
| |--Setup--->| | |
| | called: 9231000 | |
| | 1st Redirection: 5551234 | |
| | reason=cfna | |
| | 2nd Redirection: 5551001 | |
| | reason=cfb | |
| | counter=2 | |
| | | | |
| | |--INVITE sip:[EMAIL PROTECTED];user=phone-->|
| | | To: [EMAIL PROTECTED]
| | | Diversion: sip:[EMAIL PROTECTED];user=phone;reason=cfb,
| | | sip:[EMAIL PROTECTED];user=phone;reason=cfna
| | | | |
| | | routing lookup (eg. ENUM) |
| | | (9231000->3.3.3.3) |
| | | | |
| | | |--INVITE sip:3.3.3.3---->|
| | | | To: [EMAIL PROTECTED]
| | | | Diversion:
|sip:[EMAIL PROTECTED];user=phone;reason=cfb,
| | | |
|sip:[EMAIL PROTECTED];user=phone;reason=cfna
| | | | |
| | | |<-200--------------------|
| | |<-200-----------| |
| | |--ACK------------------------------------>|
| |<-Connect--| | |
|<-Connect---------| | | |
| | | | |
