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

From: "Culpepper, Bert" <[email-masked]>
Date: Wed, 11 Oct 2000 15:52:50 -0500

Hi,

Some comments on your draft.  I believe the following are typos.

7.1.4: Invite from P1->B should be INV Bob@B not INV Carol@B

7.3.2 Invite from A->C should be INVITE Carol@C not INVITE Bob@C, also
should be Diversion: Bob@B not Diversion: Carol@B

7.5.2 The 180 response is shown from D->C shouldn't it be from C->P2?

9.1 [9] Message desc. is SIP UAC to SIP proxy server 1, should be SIP UAC to
SIP UAS1

9.1 In the Alice calls for roses call flow message descriptions 6, 7, & 8
also don't match your MSC.  ACK is not shown on MSC.

These are minor, or I'm not understanding something and maybe a better
explanation is needed in the ID :-)

When reading 9.2 and looking at the MSC I thought the voicemail had enough
information to identify the correct mailbox (from the To header) if the UAC
only replaced the Request-URI with the Contact and left the To header
unchanged.  This seems like proper SIP behavior.  After reading the message
contents I see that is the case in your example.  However, SIP today does
not provide the redirecting reason, which I assume is part of your
motivation for this new header.  I will be interested to see how this
proposal is received since it can enhance a SIP application's functionality
and addresses an area of PSTN-IP interworking not otherwise covered by
existing work.

Regards,
Bert

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

---

From: Bryan Byerly <[email-masked]>
Date: Thu, 12 Oct 2000 11:53:47 -0400

> also don't match your MSC.  ACK is not shown on MSC.

Good catch on all of these!  These will be corrected in the next version of the

I-D.

> contents I see that is the case in your example.

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

>  However, SIP today does

---

From: Bryan Byerly <[email-masked]>
Date: Thu, 12 Oct 2000 13:23:35 -0400

Corrected typo in explanation below.  Should be [email-masked] instead of
[email-masked].

cheers,
Bryan

> ([email-masked] or [email-masked]) does not contain