Share via

4.3 Batched SUBSCRIBE and Piggybacked NOTIFY Example

This example shows the use of a batched SUBSCRIBE request by the client to subscribe for presence information of multiple contacts with a single subscription. It also shows how the server returns the presence information as a piggybacked notification within the 200 OK response to the SUBSCRIBE request.

Batched SUBSCRIBE request and piggybacked NOTIFY example

Figure 3: Batched SUBSCRIBE request and piggybacked NOTIFY example

The client sends a batched SUBSCRIBE request to subscribe for presence information of two other users: user2 and user3. The content-type of the SUBSCRIBE request is application/adrl+xml, and the xml body includes user2 and user3 URIs in the list of resources to subscribe to. Note that the SUBSCRIBE request also includes the Supported: ms-piggyback-first-notify header, indicating that the client supports piggybacked NOTIFY requests.

 SUBSCRIBE sip:user1@server.contoso.com SIP/2.0
  Via: SIP/2.0/TCP 11.22.33.44:14383
  Max-Forwards: 70
  From: "User 1" <sip:user1@server.contoso.com>
   ;tag=90ee61ca61c643f9b80c582e3d3e5aae;epid=f540d58d81
  To: sip:user1@server.contoso.com
  Call-ID: fb80bc9af4974421b96cebd16ea599f2
  CSeq: 1 SUBSCRIBE
  Contact:
     <sip:user1@server.contoso.com:14383;
        maddr=11.22.33.44;transport="tcp">
     ;proxy=replace
     User-Agent: RTC/1.3
     Event: presence
     Accept: 
       application/rlmi+xml,text/xml+msrtc.pidf,multipart/related
     Supported: com.microsoft.autoextend
     Supported: ms-benotify
     Proxy-Require: ms-benotify
     Supported: ms-piggyback-first-notify
     Require: adhoclist
     Supported: eventlist
     Proxy-Authorization: Kerberos qop="auth", realm="SIP 
       Communications Service", opaque="1CF1F9E0", crand="541f0209", 
       cnum="5", targetname="sip/server.contoso.com", 
       response="602306092a864886f71201020201011100
           ffffffff066ded2537aaae51fb4e69ca00ea6b20"
     Content-Type: application/adrl+xml
     Content-Length: 334
     <adhoclist xmlns="urn:ietf:params:xml:ns:adrl" 
                uri="sip:user1@server.contoso.com" 
                name="sip:user1@server.contoso.com">
       <create xmlns="">
         <resource uri="sip:user2@server.contoso.com" />
         <resource uri="sip:user3@server.contoso.com" />
       </create>
     </adhoclist>

The server accepts the SUBSCRIBE request by sending a 200 OK. In this example, the server supports piggybacked NOTIFY and includes the Supported: ms-piggyback-first-notify header in the 200 OK response. The multipart body of the 200 OK contains the batched Presence Documents for user2 and user3. If the server did not support piggybacked NOTIFY, the same body would have been sent in a separate NOTIFY instead.

  
 SIP/2.0 200 OK
 Authentication-Info: 
 Kerberos rspauth="602306092A864886F71201020201011100
                  FFFFFFFFE6B2C6E2C3D68634CD116221CDDF5C40", 
          srand="0AEB0220", snum="7", opaque="1CF1F9E0", qop="auth", 
          targetname="sip/server.contoso.com", 
          realm="SIP Communications Service"
 Contact: sip:server.contoso.com;transport=tcp
 Content-Length: 1672
 Via: SIP/2.0/TCP 11.22.33.44:14383;
    ms-received-port=1624;ms-received-cid=12c00
 From: "User 1" <sip:user1@server.contoso.com>
      ;tag=90ee61ca61c643f9b80c582e3d3e5aae;epid=f540d58d81
 To: <sip:user1@server.contoso.com>
     ;tag=A53585F7
 Call-ID: fb80bc9af4974421b96cebd16ea599f2
 CSeq: 1 SUBSCRIBE
 Expires: 24767
 Require: eventlist
 Content-Type: multipart/related; type="application/rlmi+xml";
   start=resourceList; boundary=e7904a528704417c9a90297d24081f8e
 Event: presence
 subscription-state: active;expires=24767
 ms-piggyback-cseq: 1
 Supported: com.microsoft.autoextend, ms-piggyback-first-notify,
      ms-benotify
     --e7904a528704417c9a90297d24081f8e
     Content-Transfer-Encoding: binary
     Content-ID: resourceList
     Content-Type: application/rlmi+xml
     <list xmlns="urn:ietf:params:xml:ns:rlmi" 
           uri="sip:user1@server.contoso.com" 
           version="0" fullState="true">
       <resource uri="sip:user2@server.contoso.com">
         <instance id="0" state="active" 
                   cid="user2@server.contoso.com" />
       </resource>
       <resource uri="sip:user3@server.contoso.com">
         <instance id="0" state="active" 
                   cid="user3@server.contoso.com" />
       </resource>
     </list>
     --e7904a528704417c9a90297d24081f8e
     Content-Transfer-Encoding: binary
     Content-ID: user2@server.contoso.com
     Content-Type: text/xml+msrtc.pidf
     <presentity uri="user2@server.contoso.com" 
                 xmlns="http://schemas.microsoft.com/2002/09/sip/presence" 
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
       <availability aggregate="0" description="" />
       <activity aggregate="0" description="" />
       <displayName displayName="User 2" />
     </presentity>
     --e7904a528704417c9a90297d24081f8e
     Content-Transfer-Encoding: binary
     Content-ID: user3@server.contoso.com
     Content-Type: text/xml+msrtc.pidf
     <presentity uri="user3@server.contoso.com" 
                 xmlns="http://schemas.microsoft.com/2002/09/sip/presence" 
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
       <availability aggregate="0" description="" />
       <activity aggregate="0" description="" />
       <displayName displayName="User 3" />
     </presentity>
     --e7904a528704417c9a90297d24081f8e--