Subject: [dispatch] new draft: Updates to Referred-By header

From: Salvatore Loreto <[email-masked]>
Date: Mon, 12 Oct 2009 16:49:33 +0300

Hi there,

I have just submitted to Dispatch the
"Updates to Referred-By in the Session Initiation Protocol (SIP)", 
draft-loreto-dispatch-3892bis-00.

until it will appear on the Dispatch web page you can check from here:
http://www.sloreto.com/tmp/draft-loreto-dispatch-3892bis-00.txt

Abstract

   SIP Referred-By header field conveys the referrer identity of a
   request.  This header field may be used when exploding a SIP MESSAGE
   or a SIP INVITE request to a pre-defined group URI and the
   P-Asserted-Identity header field or From header field in the exploded
   SIP requests needs to carry another value (e.g. the URI of a pre-
   defined group, or a conference focus URI).  In those cases, the
   Referred-By header field in the resulting exploded requests is set to
   the P-Asserted-Identity or to the From header field value of the
   original SIP request received before exploding, so as to convey to
   the receiver the identity of the original inviting sender.

   RFC 3892 restricts the value of the header to only one SIP URI.
   However the P-Asserted-Identity header field currently allows two URI
   values and may be expanded in the future to carry more than two
   values as described in draft-ietf-sipping-update-pai-09.  This
   document extends the Referred-By definition to support more than one
   value as well.

the draft was presented as draft-loreto-sipping-3892bis-01 during IETF 
74 in SF, and the main comment/suggestion
we got was to highlight through some use cases the importance for a 
receiver to get all the identities expressions and what
a receiver does with multiple identity expression.
To address this point we have insert the following use cases:

   The TEL URI in the Referred-By is needed in specific cases:

   o  When the message is interworked to a legacy service that does not
      support the SIP URI and a reply address is needed in that legacy
      service format.  For instance if an Instant Message is sent
      through an interworking function to an SMS user then the sender's
      TEL URI can be translated into an MSISDN in the interworking
      function and sent as the sender address in the SMS message.  The
      SMS user is then able to use this address to send replies to the
      sender.  Because it is not possible to predict ahead of time if
      the message will be interworked or not, there is a need to have
      always both the SIP URI and the TEL URI

   o  Usually clients, in order to be able to display the name or
      identity of the calling party, need the TEL URI.  In fact most of
      the addresses stored in the client's contact list are based on
      phone numbers.  So the client uses the TEL URI to find the
      person's name in the contact list and displays the name along with
      the TEL URI.

Comments and suggestions are very welcome.

cheers
Sal

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 12 Oct 2009 17:33:06 -0400

>    the receiver the identity of the original inviting sender.

What do you do if the original INVITE already has a Referred-By header?
It seems to me that you want a new header to carry this information, as
it has distinct semantics from all existing headers.

I am also curious why the From header of the exploded messages would
need to be different from the From header of the original message.

Dale