<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 class="">SUBSCRIBE <a href="mailto:sip%3Abob@biloxi.example.com">sip:bob@biloxi.example.com</a> SIP/2.0
</pre></div>The S-CSCF returns 200 OK with contact-header e.g.:<br><pre class="">Contact: sip:<a href="http://server19.example.com">server19.example.com</a></pre></div><div>From RFC 3261:<br><pre>12.1.2 UAC Behavior<br>...........<br>
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 class="">SUBSCRIBE <b>sip:<a href="http://scscf.example.com:6060">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

.....<br> 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>

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