Com SIP L TM
What is Unified Communications Presence?
Unified Communication Presence is knowing where intended recipients are, and if they are
available, in real time. To know if they are available for a phone call, instant message
or a video conference. Unified communications via SIP integrates with all systems a user
might already use, and helps those systems work together in real time.

A user setting themselves to "Do not disturb" or another user seeing that someone is on
the phone or available for a chat is examples of Presence.

SIP Presence is regulated by three SIP *methods*:
  • PUBLISH
  • SUBSCRIBE
  • NOTIFY

    PUBLISH is used by the phone or software client to notify the server what their current
    presence is [idle, offline, on the phone, busy, do not disturb, ect.].

    SUBSCRIBE is used by the phone or software client to ask the server for updates on the
    presence of another client.

    NOTIFY is used by the server to let the clients know the current presence of another
    phone or software client is.

    ComSIPL maintains presence with two server services:
  • SIPL server
  • SIPP server

    ComSIPL's SIPL server reads and maintains information concerning the PUBLISH and
    SUBSCRIBE methods from SIP packets that come in.

    ComSIPL's SIPP server brokers NOTIFY SIP packets to the clients [distributes the
    information].

    All the information used to maintain presence for the clients are stored in two files:
  • presence_w.fdb
  • registered.fdb
    ____________________________________________________________________
    SIP PUBLISH
    Below is an example of an Android cell phone SIP packet (running Linphone) publishing the
    phone's presence to the ComSIPL server: 

    PUBLISH sip:51234@10.0.0.27 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.141:5060;branch=z9hG4bK.-~bJDwuuV;rport
From: <sip:51234@10.0.0.27>;tag=HBXjpj6IT
To: sip:51234@10.0.0.27
CSeq: 20 PUBLISH
Call-ID: R3BFg0WqhB
Max-Forwards: 70
Supported: replaces, outbound, gruu, path, record-aware
Event: presence
Content-Type: application/pidf+xml
Content-Length: 489
Expires: 3600
User-Agent: LinphoneAndroid/5.1.4 (moto g power 5G - 2023) LinphoneSDK/5.2.110 (tags/5.2.110^0)

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" 
          xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" 
          xmlns:pidfonline="http://www.linphone.org/xsds/pidfonline.xsd" 
          entity="sip:51234@10.0.0.27" 
          xmlns="urn:ietf:params:xml:ns:pidf">
 <tuple id="n5z2og">
  <status>
   <basic>open</basic>
   <pidfonline:online/>
  </status>
  <contact priority="0.8">sip:51234@10.0.0.27</contact>
  <timestamp>2023-12-17T16:45:04Z</timestamp>
 </tuple>
</presence>
    ____________________________________________________________________
    SIP NOTIFY
    The ComSIPL server application, SIPP, is the ComSIPL's SIP Presence Service Broker.
    This applications uses the SIP NOTIFY message body to pass presence results to the
    SIP application clients and phones.

    The Service Broker passes the open standard PIDF format in the body below the header.

    The SIP NOTIFY message body contains the subscriber's state in the XML PIDF format.
    Made knows as: "application/pidf+xml" in the 'Content-Type:' of the SIP packet.

    Example NOTIFY with presence: 
                                                                                             
NOTIFY sip:51234@10.0.0.27 SIP/2.0                                                       <- Method line
Via: SIP/2.0/UDP 10.0.0.27;branch=z9hG4bK-d1e4c983                                       <- Start Header
To: <sip:51112@10.0.0.27>;tag=rnzgc
From: <sip:51234@10.0.0.27>
Call-ID: uyyucrjijinwadl
CSeq: 633 NOTIFY
User-Agent: ComSIPL/1.x
Event: presence
Subscription-State: active;expires=599
Contact: <sip:10.0.0.27>
Content-Type: application/pidf+xml
Content-Length: 253                                                                      <- End Header

<?xml version="1.0" encoding="UTF-8"?>                                                   <- Start Body
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="pres:51234@10.0.0.27">
  <tuple id="bs35r9f">
    <status>
      <basic>open</basic>
      <note>available</note>
    </status>
  </tuple>
</presence>
    The NOTIFY method line contains the SIP client that the packet is reporting on.

    The header contains all the required fields based on RFC 3261 with the 'Event: presence',
    the 'Subscription-State:', and 'Content-Type: application/pidf+xml' fields set.

    NOTE: The 'tag' value on the 'To:' must match the tag value on the 'From' of the
    SUBSCRIBE SIP packet. The 'Call-ID:' must match that of the SUBSCRIBE SIP packet.
    The subscription is verified with these two values.
    ____________________________________________________________________
    Obtaining Subscriber's State
    Such information includes the Subscriber's state. For example, reachable or busy.

    The following sections describe how a SIP application needs to generate a SIP
    SUBSCRIBE message to the SIPL Service Broker in order to obtain a subscriber's state ,
    and then process the SIP NOTIFY message which SIPP Service Broker sends back to the
    SIP application.

    Generating a SIP SUBSCRIBE Message
    The following SIP headers must be set in the SIP SUBSCRIBE message:

    The SIP application must set the Event header to 'Presence'.

    ____________________________________________________________________
    Processing a SIP NOTIFY Request
    Service Broker returns a subscriber's state information inside a SIP NOTIFY message body.
    The SIP NOTIFY message body containx the Subscriber's state - provided in PIDF format

    Subscription-State Header

    Content-Type Header
    The Content-Type header specifies the format of the SIP NOTIFY message body, as follows:

    "application/pidf+xml" - the body contains subscriber's state encoded in PIDF format.

    SIP Message Body
    The SIP NOTIFY message body contains information about subscriber's state as they
    were requested by the SIP application in the Event header and requested-info token
    of the SIP SUBSCRIBE message.

    The information requested by the SIP application is delivered in the message body
    as provided in an XML according to the PIDF schema.

    ____________________________________________________________________
    Subscriber's State

    Subscriber's state is provided in an XML, according to the PIDF schema.

    The following example shows how information about the subscriber's state is encoded: 
    <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="pres:123456789@10.0.0.2">
   <tuple id="sg89ae">
      <status>
         <basic>open</basic>
         <note>available</note>
      </status>
   </tuple>
</presence>
    ____________________________________________________________________
    Important PIDF Elements
    Element Description
    ____________________________________________________________________
    <presence>

    <presence> is the root element. The element includes the entity
    attribute and 0 or more <tuple> elements.

    The value of the entity attribute contains the value of the request
    received on the SIP SUBSCRIBE message.
    ____________________________________________________________________
    <tuple>

    Contains the mobile subscriber's state information that consists of a
    mandatory <status> element.
    ____________________________________________________________________
    <status>

    Contains one optional <basic> element.
    ____________________________________________________________________
    <basic>

    Specifies a subscriber's availability for communications.

    Possible values:
  • Open
  • Close
    ____________________________________________________________________
    <note>

    note is optional and contains information about the *basic* *status*