Hello,
I am testing with a client that uses the contact URI from the 2xx response to an initial SUBSCRIBE as the remote target URI in other SUBSCRIBEs within the dialog and I am having some problems with Kamailio RLS. I think the client behaviour is correct, can anyone confirm this?
This behaviour appears to be correct according to RFC 3265 section 3.1.4.1:
SUBSCRIBE is a dialog-creating method, as described in SIP [1].
And RFC 3261 section 12 states that the the contact URI from 2xx responses should be used as the remote target URI in future in-dialog requests.
However, when Kamailio receives a reSUBSCRIBE or unSUBSCRIBE it uses the R-URI of this in-dialog request as the name of a resource list to fetch from the XCAP server. This fetch fails (as the address used in the 2xx response to the initial SUBSCRIBE is hard coded as a module parameter) and so does the reSUBSCRIBE or unSUBSCRIBE.
In the unSUBSCRIBE case I don't think this resource list fetch is even required at all, and in the reSUBSCRIBE case I think the resource list name should have been cached from the initial SUBSCRIBE?
Regards,
Peter
Am 18.04.2011 14:36, schrieb Peter Dunkley:
I am testing with a client that uses the contact URI from the 2xx response to an initial SUBSCRIBE as the remote target URI in other SUBSCRIBEs within the dialog and I am having some problems with Kamailio RLS. I think the client behaviour is correct, can anyone confirm this?
Yes, it is correct.
IMO, if SUBSCRIBE has a to-tag, there shouldn't be a resource list lookup but instead it should check if there is an active subscription and refresh the subscription (and updates the remote contact if changed).
regards Klaus
On 4/18/11 3:19 PM, Klaus Darilion wrote:
Am 18.04.2011 14:36, schrieb Peter Dunkley:
I am testing with a client that uses the contact URI from the 2xx response to an initial SUBSCRIBE as the remote target URI in other SUBSCRIBEs within the dialog and I am having some problems with Kamailio RLS. I think the client behaviour is correct, can anyone confirm this?
Yes, it is correct.
IMO, if SUBSCRIBE has a to-tag, there shouldn't be a resource list lookup but instead it should check if there is an active subscription and refresh the subscription (and updates the remote contact if changed).
A quick look into the code (rls_handle_subscribe() function) shows that the rls module is taking the uri from the stored subscription dialog when the to-tag is present in a subscribe request. Can you send a sample trace of SUBSCRIBEs, at least the initial and one within the dialog, eventually with the debug messages?
Also, if you spotted something in the code, just give some hints.
Cheers, Daniel
Hi Daniel,
Sorry it has taken so long for me to get back to you. I misunderstood, and so incorrectly described this issue. I have now found and fixed it and will send in a patch shortly.
Thanks,
Peter
On Mon, 2011-04-18 at 19:55 +0200, Daniel-Constantin Mierla wrote:
On 4/18/11 3:19 PM, Klaus Darilion wrote:
Am 18.04.2011 14:36, schrieb Peter Dunkley:
I am testing with a client that uses the contact URI from the 2xx response to an initial SUBSCRIBE as the remote target URI in other SUBSCRIBEs within the dialog and I am having some problems with Kamailio RLS. I think the client behaviour is correct, can anyone confirm this?
Yes, it is correct.
IMO, if SUBSCRIBE has a to-tag, there shouldn't be a resource list lookup but instead it should check if there is an active subscription and refresh the subscription (and updates the remote contact if changed).
A quick look into the code (rls_handle_subscribe() function) shows that the rls module is taking the uri from the stored subscription dialog when the to-tag is present in a subscribe request. Can you send a sample trace of SUBSCRIBEs, at least the initial and one within the dialog, eventually with the debug messages?
Also, if you spotted something in the code, just give some hints.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Klaus Darilion -
Peter Dunkley