Hi,<br><br>you are right, it has to be the same in the original request only when the final response is a non-2xx (RFC3261, 17.1.1.3). The magic cookie is missing so &#39;0&#39; can not be a valid RFC3261 branch, anyway a &#39;0&#39; value populating a param when it should be a random value looks like a buggy situation. This happens in both 3.0.0 and 3.0.1. <br>
<br>Regarding the traces I attached in the previous mail, please, omit the NOTIFY which are being sent to <a href="http://kamailio.org">kamailio.org</a> :-), to work this around I replied this NOTIFY (which indicates the state of the REFER processing) from the Kamailio configuration with a 200OK, it works for me.<br>
<br>Thanks, <br>feedbacks are welcome  <br><br>Anton<br><br><br><div class="gmail_quote">2010/5/25 Klaus Darilion <span dir="ltr">&lt;<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>&gt;</span><br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Am 25.05.2010 12:25, schrieb Anton Roman:<div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<br>
I&#39;m trying to implement a Click2Dial service by using the dlg_bridge<br>
command from the dialog module. Although it works in this case, I found<br>
two problems in the scenario and I would like to read your opinion about<br>
them.<br>
<br>
1) Fisrt problem: the REFER generated by Kamailio doesn&#39;t contain a<br>
contact header.  As per RFC 3515, this request should have a Contact<br>
header. This REFER is not being accepted by a proprietary device. This<br>
is can be worked around with the append_hf() command from the textops<br>
module, but I don know if it is a good solution.<br>
<br>
2) The second one arises  when the ACK generated by Kamailio, goes<br>
through Kamailio (caller and calle involved in click2dial are registered<br>
on the Kamailio server): the branch of the second  via header  is not<br>
correctly populated. Its content is &#39;0&#39; when it must be tha same as in<br>
the INVITE.<br>
</blockquote>
<br></div>
AFAIK if the ACK is an ACK to a 2xx response, then the ACK is a new transaction and should have a new branch id.<br>
<br>
If 0 is a proper branch id is another question (IIRC it is valid with RFC2543 but not with 3261).<br>
<br>
This is an often raised topic which you can find discussed in the archive.<br>
<br>
regards<br><font color="#888888">
Klaus<br>
</font></blockquote></div><br>