[sr-dev] pua and pua_reginfo modules

Richard Good richard.good at smilecoms.com
Thu Dec 5 15:44:08 CET 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20131205/cd16f9e4/attachment.html>


More information about the sr-dev mailing list