<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
Hello,<BR>
<BR>
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?<BR>
<BR>
This behaviour appears to be correct according to RFC 3265 section 3.1.4.1:<BR>
<BLOCKQUOTE>
SUBSCRIBE is a dialog-creating method, as described in SIP [1].<BR>
<BR>
</BLOCKQUOTE>
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.<BR>
<BR>
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.<BR>
<BR>
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?<BR>
<BR>
Regards,<BR>
<BR>
Peter<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>