Presence and IntComm WG

[Candace Holman <>]

Ben,

[ACTION] (pre-12/8) Candace and Jamey will initiate an email discussion 
of their
proposal to modify the SER PA module so it can do presence via SUBSCRIBE 
and
NOTIFY, to accommodate clients that don't do PUBLISH.

You can remove this from the action items.  I think it has been over a 
year at low priority and is unlikely to happen unless assigned to 
someone else.

[ACTION] (pre-12/8 - in progress) Candace will add a wiki document on 
strict vs.
loose routing.

You can also remove this from the action items.  I've attached some 
notes from a summary of RFC 3261 if anyone is still curious and wants to 
add an explanation to the wiki.  I think this action item came from 
discussion of SER, and a pre-Fall-2004 version that had a bug with 
record routing when loose routing was used, but I can't remember the 
inspiration.

thanks,
Candace

Ben Chinowsky wrote:
> *Action Items as of July 19*
>
> (high priority)
> [ACTION] (7/13) Mark will look for a reference to a dating service he's
> heard about, that pops up a picture whenever someone who fits your 
> criteria
> in is the vicinity.
> [ACTION] (7/13) Dennis will look for up-to-date information on iSPOTS.
> [ACTION] (6/29 - in progress) Mark will try using Applescript to specify
> an arbitrary presence doc to publish, with a view towards using this 
> for a
> geolocation demo.
> [ACTION] (6/15) Rodger will put discussion of if and how to fix PALS and
> PALS-DEV on the agenda for a future call.
> [ACTION] (6/15) Rodger and Peter will look into the status of Jingle 
> for Gaim.
> [ACTION] (5/18) Ben T. will post the calendar-integration code 
> (written by his
> 2005 SoC student) on the Penn XMPP server; Mark will evaluate 
> prospects for
> modifying it to drive XMPP presence.
> [ACTION] (5/4) Rodger will send the PIC WG a matrix of XMPP clients to 
> try.
> [ACTION] (5/4) Rodger will send notes to assorted mailing lists, 
> asking for
> input on PIC's XMPP plan.
>
> (medium priority)
> [ACTION] (5/11 - on hold for the summer) Ben T. will look for students 
> active
> in Place Lab to work with PIC.
> [ACTION] (4/13) Rodger, Joe, Ben T., Steve, and Candace will continue 
> testing
> Gaim SIMPLE against pals.
> [ACTION] (3/2) Joe will ask Jon Peterson to join a PIC call to talk 
> about work
> in IETF SIMPLE.
> [ACTION] (1/12 - ongoing) Ben T., Candace, and Steve will continue 
> with pals-dev
> testing.
> [ACTION] (1/5 - in progress) Rodger will look for carrier reps to present
> perspectives on IMS.
> [ACTION] (12/8 - in progress) Dennis will schedule Megan Pengelly to 
> summarize
> Columbia's PIC-SER experience on a future call.
> [ACTION] (pre-12/8 - in progress) Candace will add a wiki document on 
> strict vs.
> loose routing.
> [ACTION] (pre-12/8 - in progress) Rodger will try to reach his contact at
> Barracuda Networks.
> [ACTION] (pre-12/8 - in progress) Rodger will contact Erik Lagerway.
> [ACTION] (pre-12/8 - in progress) Rodger and Joe will write up some 
> use cases
> for federations.
> [ACTION] (pre-12/8) Rodger will try to organize a call with CounterPath.
>
> (low priority)
> [ACTION] (pre-12/8) Candace and Jamey will initiate an email 
> discussion of their
> proposal to modify the SER PA module so it can do presence via 
> SUBSCRIBE and
> NOTIFY, to accommodate clients that don't do PUBLISH.
> [ACTION] (pre-12/8) Jamey will enable eyeBeam to use presence info to 
> decide
> whether messages should go straight to voicemail.
> [ACTION] (pre-12/8) Jamey will update the interface requirements 
> document.
> [ACTION] (pre-12/8) People will research skiff-like offerings from 
> various
> companies:
> - Dennis - Newbury
> - Rodger - Airespace (now part of Cisco)
> - Jeremy - Eckehau (via Walt Magnussen)
> [ACTION] (pre-12/8) Ben T. will write a short document describing the 
> motivation
> for the paths-in-the-snow approach to PIC development.
>
> *Attendees*
>
> Ben Teitelbaum (acting chair) - Internet2
> Mark Sirota - Penn
> Dennis Baron - MIT
> Neal McBurnett - Internet2
> Ben Chinowsky (scribe) - Internet2
>
> *Discussion*
>
> The group discussed aspects of geolocation. Ben T. noted that three 
> types of rich presence PIC has looked at are geolocation,
> calendaring, and things that can be inferred from geolocation and 
> calendaring together, like "are you in a quiet place now".
> Ben T. described some of the features of past PIC demos, such as 
> cross-referencing the geolocation info that tells what room
> you're in with the calendar that tells what's happening in that room, 
> to communicate e.g. availability for a phone call; and
> using network weather measurements to provide notifications of the 
> "don't bother to try video now" variety. [ACTION] Mark
> will look for a reference to a dating service he's heard about, that 
> pops up a picture whenever someone who fits your
> criteria in is the vicinity. [ACTION] Dennis will look for up-to-date 
> information on iSPOTS. Dennis called the group's
> attention to the Social Serendipity project: 
> http://reality.media.mit.edu/serendipity.php. An article on WiFi and
> location-based services, including links to some of the companies 
> involved, is at
> http://gigaom.com/2006/06/30/will-wifi-jumpstart-location-based-services/. 
>
>
> Ben T. noted that several companies are using Google Maps to add 
> geolocation info to photos at the time they're taken; Mark
> observed that the standard for this (IPTC) includes a lot of 
> human-processable information (e.g. city), not just latitude &
> longitude.
RFC 3261

 Loose Routing: A proxy is said to be loose routing if it follows
         the procedures defined in this specification for processing of
         the Route header field.  These procedures separate the
         destination of the request (present in the Request-URI) from
         the set of proxies that need to be visited along the way
         (present in the Route header field).  A proxy compliant to
         these mechanisms is also known as a loose router.

Strict Routing: A proxy is said to be strict routing if it follows
         the Route processing rules of RFC 2543 and many prior work in
         progress versions of this RFC.  That rule caused proxies to
         destroy the contents of the Request-URI when a Route header
         field was present.  Strict routing behavior is not used in this
         specification, in favor of a loose routing behavior.  Proxies
         that perform strict routing are also known as strict routers.

8.1.1.1 Request-URI

   The initial Request-URI of the message SHOULD be set to the value of
   the URI in the To field.  One notable exception is the REGISTER
   method; behavior for setting the Request-URI of REGISTER is given in
   Section 10.  It may also be undesirable for privacy reasons or
   convenience to set these fields to the same value (especially if the
   originating UA expects that the Request-URI will be changed during
   transit).

   In some special circumstances, the presence of a pre-existing route
   set can affect the Request-URI of the message.  A pre-existing route
   set is an ordered set of URIs that identify a chain of servers, to
   which a UAC will send outgoing requests that are outside of a dialog.
   Commonly, they are configured on the UA by a user or service provider
   manually, or through some other non-SIP mechanism.  When a provider
   wishes to configure a UA with an outbound proxy, it is RECOMMENDED
   that this be done by providing it with a pre-existing route set with
   a single URI, that of the outbound proxy.

   When a pre-existing route set is present, the procedures for
   populating the Request-URI and Route header field detailed in Section
   12.2.1.1 MUST be followed (even though there is no dialog), using the
   desired Request-URI as the remote target URI.

8.1.1.8 Contact

   The Contact header field provides a SIP or SIPS URI that can be used
   to contact that specific instance of the UA for subsequent requests.
   The Contact header field MUST be present and contain exactly one SIP
   or SIPS URI in any request that can result in the establishment of a
   dialog.  For the methods defined in this specification, that includes
   only the INVITE request.  For these requests, the scope of the
   Contact is global.  That is, the Contact header field value contains
   the URI at which the UA would like to receive requests, and this URI
   MUST be valid even if used in subsequent requests outside of any
   dialogs.

   If the Request-URI or top Route header field value contains a SIPS
   URI, the Contact header field MUST contain a SIPS URI as well.

   For further information on the Contact header field, see Section
   20.10.

12.2.1 UAC Behavior

12.2.1.1 Generating the Request

   A request within a dialog is constructed by using many of the
   components of the state stored as part of the dialog.

   The URI in the To field of the request MUST be set to the remote URI
   from the dialog state.  The tag in the To header field of the request
   MUST be set to the remote tag of the dialog ID.  The From URI of the
   request MUST be set to the local URI from the dialog state.  The tag
   in the From header field of the request MUST be set to the local tag
   of the dialog ID.  If the value of the remote or local tags is null,
   the tag parameter MUST be omitted from the To or From header fields,
   respectively.

      Usage of the URI from the To and From fields in the original
      request within subsequent requests is done for backwards
      compatibility with RFC 2543, which used the URI for dialog
      identification.  In this specification, only the tags are used for
      dialog identification.  It is expected that mandatory reflection
      of the original To and From URI in mid-dialog requests will be
      deprecated in a subsequent revision of this specification.

   The Call-ID of the request MUST be set to the Call-ID of the dialog.
   Requests within a dialog MUST contain strictly monotonically
   increasing and contiguous CSeq sequence numbers (increasing-by-one)
   in each direction (excepting ACK and CANCEL of course, whose numbers
   equal the requests being acknowledged or cancelled).  Therefore, if
   the local sequence number is not empty, the value of the local
   sequence number MUST be incremented by one, and this value MUST be
   placed into the CSeq header field.  If the local sequence number is
   empty, an initial value MUST be chosen using the guidelines of
   Section 8.1.1.5.  The method field in the CSeq header field value
   MUST match the method of the request.

      With a length of 32 bits, a client could generate, within a single
      call, one request a second for about 136 years before needing to
      wrap around.  The initial value of the sequence number is chosen
      so that subsequent requests within the same call will not wrap
      around.  A non-zero initial value allows clients to use a time-
      based initial sequence number.  A client could, for example,
      choose the 31 most significant bits of a 32-bit second clock as an
      initial sequence number.

   The UAC uses the remote target and route set to build the Request-URI
   and Route header field of the request.

   If the route set is empty, the UAC MUST place the remote target URI
   into the Request-URI.  The UAC MUST NOT add a Route header field to
   the request.

   If the route set is not empty, and the first URI in the route set
   contains the lr parameter (see Section 19.1.1), the UAC MUST place
   the remote target URI into the Request-URI and MUST include a Route
   header field containing the route set values in order, including all
   parameters.

   If the route set is not empty, and its first URI does not contain the
   lr parameter, the UAC MUST place the first URI from the route set
   into the Request-URI, stripping any parameters that are not allowed
   in a Request-URI.  The UAC MUST add a Route header field containing
   the remainder of the route set values in order, including all
   parameters.  The UAC MUST then place the remote target URI into the
   Route header field as the last value.

   For example, if the remote target is 
sip:user@remoteua
 and the route
   set contains:

      <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>

   The request will be formed with the following Request-URI and Route
   header field:

   METHOD sip:proxy1
   Route: 
<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>

      If the first URI of the route set does not contain the lr
      parameter, the proxy indicated does not understand the routing
      mechanisms described in this document and will act as specified in
      RFC 2543, replacing the Request-URI with the first Route header
      field value it receives while forwarding the message.  Placing the
      Request-URI at the end of the Route header field preserves the

      information in that Request-URI across the strict router (it will
      be returned to the Request-URI when the request reaches a loose-
      router).

   A UAC SHOULD include a Contact header field in any target refresh
   requests within a dialog, and unless there is a need to change it,
   the URI SHOULD be the same as used in previous requests within the
   dialog.  If the "secure" flag is true, that URI MUST be a SIPS URI.
   As discussed in Section 12.2.2, a Contact header field in a target
   refresh request updates the remote target URI.  This allows a UA to
   provide a new contact address, should its address change during the
   duration of the dialog.

   However, requests that are not target refresh requests do not affect
   the remote target URI for the dialog.

   The rest of the request is formed as described in Section 8.1.1.

   Once the request has been constructed, the address of the server is
   computed and the request is sent, using the same procedures for
   requests outside of a dialog (Section 8.1.2).

      The procedures in Section 8.1.2 will normally result in the
      request being sent to the address indicated by the topmost Route
      header field value or the Request-URI if no Route header field is
      present.  Subject to certain restrictions, they allow the request
      to be sent to an alternate address (such as a default outbound
      proxy not represented in the route set).