[sr-dev] pua and pua_reginfo modules

[Daniel-Constantin Mierla]

Hello,

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.

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.

Cheers,
Daniel

On 05/12/13 15:44, Richard Good wrote:
> Hi
>
> I am re-using the pua_reginfo module to implement P-CSCF subscription 
> to Registration-State information at the S-CSCF.
>
> For the first SUBSCRIBE everything works fine and as per RFC 3680 the 
> SUBSCRIBE has the presentity URI as request-URI, e.g.
> SUBSCRIBEsip:bob at biloxi.example.com  <mailto:sip%3Abob at biloxi.example.com>  SIP/2.0
> The S-CSCF returns 200 OK with contact-header e.g.:
> Contact: sip:server19.example.com  <http://server19.example.com>
> From RFC 3261:
> 12.1.2 UAC Behavior
> ...........
>
> The remote target MUST be set to the URI
>     from the Contact header field of the response.
> So any subsequent SUBSCRIBE has its remote target (and hence 
> request-URI) changed to the contact returned in the 200 OK.
>
> So any subsequent SUBSCRIBE requests have request-URI:
> SUBSCRIBE*sip:scscf.example.com:6060  <http://scscf.example.com:6060>*  SIP/2.0
> Currently our S-CSCF implementation uses the request-URI to look up 
> the presentity URI so any subsequent SUBSCRIBE requests fail.
>
> From RFC 3265:
> 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.
>
> 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?
>
> Regards
> Richard.
>
> This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20131211/cde2b71a/attachment.html>