5 Dec
2013
5 Dec
'13
4:44 p.m.
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@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
11 Dec
11 Dec
12:11 p.m.
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@biloxi.example.com <mailto:sip%3Abob@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(a)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
12:38 p.m.
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(a)gmail.com>wrote;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@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@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(a)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
4004
days inactive
4010
days old
2 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Richard Good