> -----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.
> 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.
> 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.
> 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]
---
Igor Slepchin
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors