[OpenSIPS-Users] Wrong Contact in location table
Răzvan Crainea
razvan at opensips.org
Tue Nov 7 09:54:53 EST 2017
Hi, Dragomir!
So you did not have the parameter provisioned at all? Or what was the
initial issue?
Best regards,
Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com
On 11/07/2017 03:55 PM, Dragomir Haralambiev wrote:
> Thanks Razvan and Hristo,
>
> Add in my script follow lines and incoming calls worked fine:
>
> modparam("registrar", "received_avp", "$avp(received)")
> modparam("nathelper","received_avp", "$avp(received)")
>
> Thank you!
>
> 2017-11-07 12:25 GMT+02:00 Hristo Donev <nocbgtelcom at gmail.com
> <mailto:nocbgtelcom at gmail.com>>:
>
> YES !!!
>
> Here is problem:
>
> I have follow line:
> modparam("nathelper|registrar","received_avp", "$avp(42)")
>
> This not working.
>
> All is OK if I use:
> modparam("nathelper","received_avp", "$avp(42)")
> modparam("registrar", "received_avp", "$avp(42)")
>
>
>
>
>
> 2017-11-07 10:55 GMT+02:00 Răzvan Crainea <razvan at opensips.org
> <mailto:razvan at opensips.org>>:
>
> Hi, Dragomir!
>
> This is something that I noticed from the first email you have
> sent - the fix_nated_register() function is not called, or
> does not work properly. Can you also print the avp you are
> setting in the received_avp[1]. Also, call script trace for
> the reply too.
>
> [1]
> http://www.opensips.org/html/docs/modules/2.4.x/nathelper.html#idp5510048
> <http://www.opensips.org/html/docs/modules/2.4.x/nathelper.html#idp5510048>
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Developer
> www.opensips-solutions.com <http://www.opensips-solutions.com>
>
> On 11/06/2017 06:18 PM, Dragomir Haralambiev wrote:
>> Hi,
>>
>> Thanks for your email.
>>
>> Here is part of my location table:
>>
>> contact_id username domain contact
>> received path expires q callid
>> cseq last_modified flags cflags user_agent
>> socket methods sip_instance attr
>> ------------------- --------- ------
>> --------------------------------------------------------------------------
>> -------- ------ ------------------- ------
>> ------------------------------------------------ ------
>> ------------------- ------ ---------
>> -------------------------------- -----------------------
>> ------- ------------ --------
>> 181494352482801881 57996206 (NULL)
>> sip:57996206 at 192.168.22.206:5062
>> <http://sip:57996206@192.168.22.206:5062> (NULL)
>> (NULL) 2017-11-06 17:58:48 -1.00 1162502851 at 192.168.22.206
>> <mailto:1162502851 at 192.168.22.206>
>> 162 2017-11-06 17:52:48 0 NAT_BFLAG Yealink SIP-T19P
>> 31.72.0.75 udp:OpenSips_IP:5060 16383 (NULL) (NULL)
>> 181654460760464436 57996204 (NULL)
>> sip:57996204 at 192.168.22.204:5060
>> <http://sip:57996204@192.168.22.204:5060> (NULL)
>> (NULL) 2017-11-06 17:59:02 -1.00
>> 0_1763370066 at 192.168.22.204
>> <mailto:0_1763370066 at 192.168.22.204>
>> 179 2017-11-06 17:53:02 0 NAT_BFLAG Yealink
>> SIP-T21P_E2 52.81.0.25 udp:OpenSips_IP:5060 16383
>> (NULL) (NULL)
>> Why "received" field is blank?
>> Where could be the problem?
>>
>>
>> 2017-11-06 11:44 GMT+02:00 Răzvan Crainea
>> <razvan at opensips.org <mailto:razvan at opensips.org>>:
>>
>> Hi, Dragomir!
>>
>> If you simply do fix_nated_register() on the REGISTER
>> messages, all these will be sorted out. Moreover, it's
>> actually not correct to change the contact of the user,
>> because in the SIP message it might expect to have
>> exactly what he sent.
>> When using fix_nated_register(), there is another field
>> (called Received) that stores the actual IP and port
>> where the REGISTER came from, and when an invite comes
>> in, it is automatically set by the lookup() function in
>> the DST uri, without changing the contact (the contact
>> may still be private).
>>
>> So simply calling fix_nated_register() should fix this
>> issue for all scenarios.
>> I initially though that you were using the Contact from
>> something else and you really need that value there.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Developer
>> www.opensips-solutions.com
>> <http://www.opensips-solutions.com>
>>
>> On 11/03/2017 09:36 PM, Dragomir Haralambiev wrote:
>>> Hi,
>>>
>>> Why I need the real IP and port in location table?
>>>
>>> Now I make only outgoing call. Everything works fine on
>>> the following scenario.:
>>> User -----> Opensips ------> ITSP
>>>
>>> If I not have real IP in location table incoming calls
>>> not be implemented.
>>> ITSP ----> Opensips ---->?
>>>
>>> Opensips get IP from location table and try to send
>>> call. But in location table have not real IP.
>>> I see how the Opensips try to send call to 192.168.2.34.
>>>
>>> This is the main problem.
>>>
>>> 2017-11-03 11:45 GMT+02:00 Răzvan Crainea
>>> <razvan at opensips.org <mailto:razvan at opensips.org>>:
>>>
>>> Unfortunately I just realised that you cannot change
>>> the Contact header for this scenario.
>>> And to be honest I don't really understand why you
>>> are trying to change it - if you need the real IP
>>> and port, you can take them from the received field.
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Developer
>>> www.opensips-solutions.com
>>> <http://www.opensips-solutions.com>
>>>
>>> On 11/02/2017 11:43 PM, Dragomir Haralambiev wrote:
>>>> Hi,
>>>>
>>>> Here is part of my script:
>>>> ....
>>>> modparam("registrar", "mcontact_avp", "$avp(register)")
>>>> .....
>>>>
>>>> if (t_check_status("2[0-9][0-9]")) {
>>>> $log_level = 5;
>>>> script_trace( 1, "$rm from $si, ruri=$ru,
>>>> ct=$ct.fields(uri) avp(register)=$avp(register)",
>>>> "me");
>>>> route(save_location);
>>>> .......
>>>> }
>>>>
>>>> You can see log here:
>>>> https://pastebin.com/WWQ9Mmh4
>>>>
>>>> Here is the replacement contact:
>>>>
>>>> DBG:registrar:build_contact: created Contact HF:
>>>> Contact: <sip:55595009 at 192.168.22.138:5062
>>>> <http://sip:55595009@192.168.22.138:5062>>;expires=360
>>>> DBG:registrar:save: replacing contact uri
>>>> [sip:55595009 at 188.23.232.10:1043
>>>> <http://sip:55595009@188.23.232.10:1043>] with
>>>> [sip:55595009 at 192.168.22.138:5062
>>>> <http://sip:55595009@192.168.22.138:5062>]
>>>>
>>>> How to stop replacing contact from
>>>> 188.23.232.10:1043 <http://188.23.232.10:1043> to
>>>> 192.168.22.138:5062 <http://192.168.22.138:5062> ?
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20171107/bc9ddff0/attachment-0001.html>
More information about the Users
mailing list