Subject: Re: [sipcore] SIP Push with SIP notifications: Way forward - The text using PRID - The pull request

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Sep 2018 13:46:36 +0000

Pull request created:

https://github.com/cdh4u/draft-sip-push/pull/22

Regards,

Christer

On 16/09/18 15:29, "sipcore on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,
    
    I have put together initial text to support mid-dialog NOTIFY request.
    
    I put everything in a dedicated section.
    
    If people are ok with the approach, I will create a proper pull request.
    
    ----
    
    X. Subscription Dialog Considerations
    
    when a UA creates a subscription dialog [RFC6665], there may be a long period between mid-dialog SIP NOTIFY
    request. During that time the UA might get suspended, and needs to be awaken in order to receive
    such NOTIFY request. However, unlike an initial request for a dialog, the NOTIFY request will not contain
    the pn- SIP URI parameters needed by the proxy to request a push notification towards the UA. Instead, the proxy
    need to support a mechanism, where it stores the information needed to request a push notification towards the UA, 
    and when the proxy receives the initial SUBSCRIBE request for the subscription dialog it needs to associate the 
    subscription dialog with that information. This section describes the UA- and proxy procedures for such mechanism.
    
    The procedures in this section are applied in addition to the generic procedures for the UA and the proxy.
    
    X.1. SIP UA Beahvior
    
    X.1.1. SUBSCRIBE
    
    When the UA sends a SIP SUBSCRIBE request (initial or subscription refresh), if the UA wants to receive push notification 
    requests when the proxy receives NOTIFY requests addressed towards the UA, the UA MUST include a '+sip.prid' Contact header 
    field parameter in the SUBSCRIBE request. The UA MUST include the same parameter value that it included in the pn-prid SIP URI
    parameter of the last REGISTER request.
    
    X.2. SIP Proxy Behavior
    
    X.2.1. REGISTER
    
    When the UA receives a REGISTER request from the UA, the proxy MUST store the information (the pn- SIP URI parameters) 
    needed to request push notifications associated with the registration towards the UA, and use the pn-prid SIP URI parameter 
    value as key to access the data. The proxy MUST store the information until the registration expires. As describe in section 5.2, 
    the proxy needs to be able to retrieve the registration state information from the registrar using some mechanism. 
    
    X.2.2 SUBSCRIBE
    
    When the proxy receives an initial SUBSCRIBE request for a subscription dialog from a UA, the request 
    contains a '+sip.prid' Contact header field parameters, and the proxy has stored the information needed 
    in order to request push notifications towards the UA [ref-to-reg-section], the proxy MUST store the 
    subscription dialog information, including the '+sip.prid' Contact header field parameter value. In addition,
    the proxy MUST add a Record-Route header field to the request and add itself to the dialog route [RFC3261]
    before forwarding the request.
    
    If the proxy receives a mid-dialog SUBSCRIBE subscription refresh request from the UA, and the request contains
    a '+sip.prid' Contact header field parameter with an updated parameter value, the proxy MUST update the value
    in the stored dialog information.
    
    X.2.3. NOTIFY
    
    When the proxy receives a mid-dialog NOTIFY request addressed towards the UA, the proxy has stored the associated
    dialog information [ref-to-sub-section], and the proxy is able to retrieve the stored information needed to request
    a push notification towards the UA [ref-to-reg-equest], the proxy MUST request a push notification towards the UA.
    Once the proxy has received the triggered REGISTER request, and the associated successful response, the proxy can
    forward the NOTIFY request towards the UA.
    
    Otherwise the proxy MUST reject the NOTIFY request and send a 480 (Temporarily Unavailable) error response.
    
    As described in [section 5.3.2], while waiting for the push notification request to
    succeed, and the associated REGISTER request to arrive from the SIP UA, the proxy needs 
    to take into consideration that the transaction associated with the NOTIFY request will 
    eventually time out at the sender of the request (UAC), and the sender will consider the
    transaction a failure.

    
    _______________________________________________
    sipcore mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sipcore