[sr-dev] pua and pua_reginfo modules

[Richard Good]

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.

Regards
Richard.



On 11 December 2013 12:11, Daniel-Constantin Mierla <miconda at gmail.com>wrote:

>  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.
>
> SUBSCRIBE sip:bob at biloxi.example.com SIP/2.0
>
>  The S-CSCF returns 200 OK with contact-header e.g.:
>
> Contact: sip: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 listsr-dev at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>

This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20131211/49245481/attachment.html>