Subject: RE: [SIP] draft-levy-sip-diversion-00.txt

From: "Culpepper, Bert" <[email-masked]>
Date: Fri, 13 Oct 2000 16:00:19 -0500

Thank you for your response.  My comments are below.

> -----Original Message-----
> From: Bryan Byerly [mailto:[email-masked]]
> Sent: Friday, October 13, 2000 4:28 PM
> To: Culpepper, Bert
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [SIP] draft-levy-sip-diversion-00.txt
> 
> 
> "Culpepper, Bert" wrote:
> 
> > Hi:
> >
> > This is just a "sanity check" on my part.  A SIP UA can
> > send an INVITE to proxy server (host) independent of the
> > host specified in the Request-URI.  The proxy would
> > forward this message on according to its policies.  If you
> > consider the proxy server provides no additional
> > functionality than that defined in the SIP RFC, the UA
> > would use the 10-digit DN in your voice mail example in
> > both the Request-URI and To: header.
> 
> True.  Although I'm not sure how the UAC in the example above knew to
> call the
> voicemail server directly.  Was the intent of the UAC: "I want to call
> Bob's
> voicemail?", or "I want to call Bob"?

In my scenario here the UAC wanted to call Bob and Bob's UA forwarded
the call to voicemail.  Here's the forwarding intelligence is in Bob's UA.

> 
> >  If a call is
> > forwarded to voice mail, I'd expect the forwarding
> > UA/proxy to modify the Request-URI to be that of the
> > voice mail service but leave the To: header unchanged.
> 
> Yes, per RFC2543, the To: header should remain unchanged.
> 
> > A SIP UA receiving the forwarded session can determine
> > its for voice mail by the Request-URI and identify the
> > mailbox from the To: header.
> 
> There is a subset of all possible calls for which the above approach will
> work.  Specifically,
> a) calls that have not been diverted multiple times
> AND
> b) calls which originated at the UAC with a global URL.

I agree, in the case of multiple redirections the Diversion information
is needed if the session is to end up in mailbox of the last diverting
UA (or proxy on behalf of the UA).

Thanks,
Bert

> 
> > However, the proxy servers in these examples are
> > providing additional features to their users.  Such as
> > "4-digit dialing".  Encountering this kind of service is to be
> > expected in some networks, therefore the need for the
> > Diversion information.  Do you agree?
> 
> Yes.  Exactly.
> 
> This is a good discussion.  Do you mind forwarding this to the main
> SIP list?
> 
> thanks for your help,
> Bryan
> 
> > Thanks,
> > Bert
> >
> > -----Original Message-----
> > From: Bryan Byerly [mailto:[email-masked]]
> > Sent: Thursday, October 12, 2000 1:24 PM
> > To: Culpepper, Bert
> > Cc: [email-masked]; [email-masked]; SIP List
> > Subject: Re: [SIP] draft-levy-sip-diversion-00.txt
> >
> > > There are two reasons that the To: header is insufficient to provide
> > > Diversion information:
> > > 1) The To: header may contain a private URL.
> > > 2) Even if the To: header contains a public URL, when there are
multiple
> > > Diversions, the To header would not reflect the information on all the
> > > Diversions that occurred.  For example, the third-party application
service
> > > provider may (typically) want to see information on the final
Diversion that
> > > occurred (instead of the first Diversion).
> > >
> > > Here's a SIP username style example of (1) using a night service:
> > > Assume that 2 pizza delivery companies, PapaJohns and Dominos, both
> > > contract with the third-party night service company, NightServ.com.
PapaJohns
> > > contracts with NightService.com to provide night service for
> > > [email-masked].
> > > Dominos contracts with NightService.com to provide night service for
> > > [email-masked].  The Diversion header is inserted by the
PapaJohn/Domino's
> > > proxy on call forward time-of-day to nightserv.com.
> > >
> > > Now, when Alice sends "INVITE [email-masked]", her proxy could
> > > resolve to
> > >
> > > "[email-masked]".  However, when Bob sends "INVITE
> > > [email-masked]",
> > > his proxy could resolve to "[email-masked]".   Specifically notice
that the
> > > contents of the To: header ([email-masked] or
[email-masked])
> > > did not provide sufficient information to the third-party night
service provider to
> > >
> > > be able to respond intelligently with "Hello, this is PapaJohns" or
"Hello,
> > > this is Dominos".
> > >
> > > Here's a PSTN style example of (1) using a third-party voicemail
service:
> > > A third-party voicemail server may provide voicemail service for
111-555-1234
> > > and 222-555-1234.  When Alice calls "INVITE [email-masked]",
> > > proxy.ispA.com expands the number to 111-555-1234.  When Bob calls
> > > "INVITE [email-masked]", proxy.ispB.com expands the number to
> > > 222-555-1234.  Notice that, on Call Forward No Answer, the To: header
> > >
> > > ([email-masked] or [email-masked]) does not contain
> > >
> > > sufficient information to forward to the appropriate voice mailbox.
> > >
> > > When a request (INVITE) arrives at a SIP entity, only the Request-URI
(not the
> > > To: header) is "guaranteed" to be locally understood by that entity.
(If the
> > > Request-URI is not understood, the PDU would be 404ed).  Thus, in
general, the
> > > To: header is only useful for determining uniqueness of a transaction
(as part
> > > of the four-tuple: To:, From:, Call-ID, CSeq:) and is not useful for
triggering
> > >
> > > called feature logic.  In the general case, the Request-URI (and not
the
> > > To: header) should be used to trigger called feature logic.  That's
why the
> > > Diversion header copies the contents of the Request-URI when the
Diversion
> > > occurred.
> > >
> > > Thanks again for your help!
> > > Bryan
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip