<div dir="ltr">Thanks Daniel - I'll put a change into ims_registrar_scscf:  when processing subscriptions to reg events allow the ruri to be the contact of the S-CSCF and get the presentity from the to-header.<div><br>
</div><div>Regards</div><div>Richard.</div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On 11 December 2013 12:11, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    for requests within dialog the r-uri has to be the contact from the
    200ok that created the dialog. This is the general rule, I don't
    remember any spec amending that for subscriptions.<br>
    <br>
    As long as there is a to-tag, the requests has to end up to the
    entity that generated its value, that being specified by a contact
    header in initial request or its reply.<br>
    <br>
    Cheers,<br>
    Daniel<div><div class="h5"><br>
    <br>
    <div>On 05/12/13 15:44, Richard Good wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>Hi<br>
                  <br>
                </div>
                I am re-using the pua_reginfo module to implement P-CSCF
                subscription to Registration-State information at the
                S-CSCF.<br>
                <br>
              </div>
              For the first SUBSCRIBE everything works fine and as per
              RFC 3680 the SUBSCRIBE has the presentity URI as
              request-URI, e.g.<br>
              <pre>SUBSCRIBE <a href="mailto:sip%3Abob@biloxi.example.com" target="_blank">sip:bob@biloxi.example.com</a> SIP/2.0
</pre>
            </div>
            The S-CSCF returns 200 OK with contact-header e.g.:<br>
            <pre>Contact: sip:<a href="http://server19.example.com" target="_blank">server19.example.com</a></pre>
          </div>
          <div>From RFC 3261:<br>
            <pre>12.1.2 UAC Behavior
...........

The remote target MUST be set to the URI
   from the Contact header field of the response.</pre>
          </div>
          <div>So any subsequent SUBSCRIBE has its remote target (and
            hence request-URI) changed to the contact returned in the
            200 OK. <br>
            <br>
            So any subsequent SUBSCRIBE requests have request-URI:<br>
            <pre>SUBSCRIBE <b>sip:<a href="http://scscf.example.com:6060" target="_blank">scscf.example.com:6060</a></b> SIP/2.0</pre>
          </div>
          <div>Currently our S-CSCF implementation uses the request-URI
            to look up the presentity URI so any subsequent SUBSCRIBE
            requests fail.<br>
          </div>
          <div><br>
          </div>
          <div>From RFC 3265:<br>
            <pre>3.1.4.2. Refreshing of Subscriptions

.....
 The handling for such a request is the same as for
   the initial creation of a subscription except as described below.
</pre>
            <br>
          </div>
          <div>Does anyone know what subsequent SUBSCRIBE requests
            should have in their request-URI?  The contact returned in
            the first 200 OK (the S-CSCF contact) as per RFC 3261 or the
            same as the initial SUBSCRIBE as per RFC 3265 with the
            presentity URI in the request-URI?<br>
            <br>
            Regards<br>
            Richard.<br>
          </div>
          <div><br>
          </div>
        </div>
      </div>
      </div></div><pre>This email is subject to the disclaimer of Smile Communications at <a href="http://www.smilecoms.com/disclaimer" target="_blank">http://www.smilecoms.com/disclaimer</a>


<fieldset></fieldset>
<pre>_______________________________________________
sr-dev mailing list
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>

</pre><span class="HOEnZb"><font color="#888888">
    </font></span></blockquote><span class="HOEnZb"><font color="#888888">
    <br>
    <pre cols="72">-- 
Daniel-Constantin Mierla - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
<a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a></pre>
  </font></span></div>

<br>_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
<br></blockquote></div><br></div></div>

<pre>This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer