[SR-Users] no Contact in REFER generated with dlg_bridge

[Anton Roman]

Hi,

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 '0' can not be a valid RFC3261 branch, anyway a '0' 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.

Regarding the traces I attached in the previous mail, please, omit the
NOTIFY which are being sent to kamailio.org :-), 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.

Thanks,
feedbacks are welcome

Anton


2010/5/25 Klaus Darilion <klaus.mailinglists at pernau.at>

>
>
> Am 25.05.2010 12:25, schrieb Anton Roman:
>
>  Hi all,
>>
>> I'm trying to implement a Click2Dial service by using the dlg_bridge
>> command from the dialog module. Although it works in this case, I found
>> two problems in the scenario and I would like to read your opinion about
>> them.
>>
>> 1) Fisrt problem: the REFER generated by Kamailio doesn't contain a
>> contact header.  As per RFC 3515, this request should have a Contact
>> header. This REFER is not being accepted by a proprietary device. This
>> is can be worked around with the append_hf() command from the textops
>> module, but I don know if it is a good solution.
>>
>> 2) The second one arises  when the ACK generated by Kamailio, goes
>> through Kamailio (caller and calle involved in click2dial are registered
>> on the Kamailio server): the branch of the second  via header  is not
>> correctly populated. Its content is '0' when it must be tha same as in
>> the INVITE.
>>
>
> 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.
>
> If 0 is a proper branch id is another question (IIRC it is valid with
> RFC2543 but not with 3261).
>
> This is an often raised topic which you can find discussed in the archive.
>
> regards
> Klaus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20100525/3d439721/attachment.htm>