[SR-Users] [NOT Solved]Creating RURI ($ru) from Contact ($ct)

[Aft nix]

On Tue, May 29, 2012 at 3:03 PM, Aft nix <aftnix at gmail.com> wrote:
> On Tue, May 29, 2012 at 2:57 PM, Daniel-Constantin Mierla
> <miconda at gmail.com> wrote:
>> Hello,
>>
>> in kamailio, if you want to apply immediately the changes done to the sip
>> request, then use msg_apply_changes() from textopsx module. Then you can
>> access it with the contact PV.
>>
>> Also, the pvs for source ip and port are $si and $sp -- see the PV cookbook
>> in the wiki site at kamailio.org
>>
>> Cheers,
>> Daniel
>>
>
> Hi Daniel,
>
> Thank you for quick reply. I will test both and post updates.
> Cheers.
>

Hi Daniel

The problem which i was facing is solved by adding a call
"msg_apply_changes()" after route[NATDETECT].

But i'm facing a new problem. As its the "callee" who always generates
the malformed "BYE", so i need to differentiate if the BYE is from
caller or callee.

It can be done with hardcoded IP address of my gateway , but it does
not seems OK to me.

So i'm interested if RFC 3261 provides any mechanism by which we can
differentiate a BYE whether its from "caller" or "callee".

Cheers.


>>
>> On 5/29/12 10:39 AM, Aft nix wrote:
>>>
>>> Hi,
>>>
>>> Sorry guyz, the problem is not solved as i thought. The script worked
>>> perfectly in my lab where i did'nt know that the wifi router is a so
>>> called "sip friendly router". It fixes broken contacts so it worked
>>> perfectly in my lab.
>>>
>>> But in my production server it did'nt work.
>>>
>>> Problem is when i put "contact" in hash table entry like following :
>>>
>>> sht(a=>$ci) = $ct;
>>>
>>> it puts the broken contact adress( I mean contact address with private
>>> IP) into the hashtable.
>>>
>>> At first i put my code after the execution of "fix_nated_contact()".
>>> But it did'nt work. Then i put a xlog() to print $ct. And to my
>>> surprise i saw that its printing the private IP instead of the public
>>> one. After searching through mailing list archives i came across this
>>> :
>>>
>>> http://lists.iptel.org/pipermail/serusers/2006-September/030511.html
>>>
>>> According to this although the contact is fixed with received IP and
>>> port, its not applied to the message buffer and kept in temporary
>>> storage. when the message is about to be sent over sockets this
>>> temporary storage is applied over the the original message buffer.
>>> pseudo variables like $ct will always reference to the original
>>> message, not the modified one after fix_nated_contact().
>>>
>>> So to populate my hashtable, i have to choices:
>>>
>>> 1. I can reference src_ip and src_port , put a ":" between them  like
>>> following :
>>>
>>> sht(a=>$ci) = $fU + src_ip + ":" + src_port (Please help with the
>>> correct syntax for string concatenation).
>>>
>>> 2. Or if possible i reference the changed contact from the temporary
>>> storage, and put this into my hashtable.
>>>
>>> Please direct me which way should i go.
>>>
>>> Cheers.
>>>
>>> On Mon, May 28, 2012 at 8:25 PM, Aft nix <aftnix at gmail.com> wrote:
>>>>
>>>> Hi all,
>>>> I'm posting the script which worked. In future if anybody faces the
>>>> same problem can get a solution out of this.
>>>>
>>>> In request_route:
>>>>
>>>>  #!ifdef WITH_HASH
>>>>         if (is_method("INVITE") && !has_totag()){
>>>>                 xdbg ("Contact [$ct] with Callid [$ci]");
>>>>                 $sht(a=>$ci) = $ct;
>>>>         }
>>>>  #!endif
>>>>
>>>> in route[WITHINDLG]
>>>>
>>>> #!ifdef WITH_HASH
>>>>                                 xdbg ("ruri [$ru]");
>>>>                                 if ($(sht(a=>$ci){nameaddr.uri}) != $ru){
>>>>                                         xdbg ("hash table entry
>>>> [$sht(a=>$ci)]");
>>>>                                         $ru =
>>>> $(sht(a=>$ci){nameaddr.uri});
>>>>                                         sht_rm_name_re("ha=>$ci");
>>>>                                         xdbg ("rewriting ruri to [$ru]");
>>>>                                 }
>>>>  #!endif
>>>>
>>>>
>>>> Thanks everyone for the help. I'm marking this thread as solved.
>>>> --
>>>> -aft
>>>>
>>>>
>>>> --
>>>> -aft
>>>
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.com
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
>> http://asipto.com/u/katu
>>
>>
>>
>
>
>
> --
> -aft



-- 
-aft