Re: [OpenSIPS-Users] Fw: migration doc missing info

[Pasan Meemaduma]

Hi Razvan,
Yes. I installed it from debian package.
 

On Monday, 11 April 2016, 17:34, Răzvan Crainea  wrote:
 

  Hi, Pasan!
 
 I guess you are installing OpenSIPS from the deb packages, right? Please 
confirm whether you do or not.
 I've update the document as requested[1].
 
 [1] http://www.opensips.org/Documentation/Migration-2-1-0-to-2-2-0#toc3
 
 Thanks,
  Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com On 04/11/2016 05:00 AM, Pasan Meemaduma wrote:
  
   
 
  On Friday, 8 April 2016, 11:40, Pasan Meemaduma  
wrote:
  
 
 Hi Guys, 
  I'm migrating my test opensips installation from 2.1 -> 2.2 and found that 
module path being changed in 2.2 as below, 
  mpath="/usr/lib/opensips/modules/" -> 
mpath="/usr/lib/x86_64-linux-gnu/opensips/modules/"


But this wasn't indicated in the migration docs.

http://www.opensips.org/Documentation/Migration-2-1-0-to-2-2-0

Hope you can fix that, so ppl won't surprise with missing module errors -_-

 Regards Pasan
 
 
  
  
 ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
 
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


  ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Call-id issue in Cancel message generated by tm / $T_fr_inv_timeout

[John Nash]

Hello Bogdan,

The confusion was we received request timeout in two cases ..
1- Gateway did not respond at all not even a trying. (We may take action to
disable gateway if too many of such cases)
2- Gateway sent trying and ringing but B party did not answer the call and
it timed out. (This is no fault of gateway)

This was solved for me by checking which timer expired (fr_timer or
fr_inv_timer) I was able to solve it by using your old post.

Regards

John




On Sat, Apr 23, 2016 at 1:52 PM, Bogdan-Andrei Iancu 
wrote:

> Hi John,
>
> A Request Terminated is generated in response of a received CANCEL
> request. In the scenario of a local timeout, there is not received cancel -
> it is a timeout event. I do not see any confusion in the reason string in
> CDR.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 19.04.2016 17:49, John Nash wrote:
>
> Ok got it thanks. I also noticed that transactions cancelled because of
> fr_inv_timeout , CDR records as "Request timeout". It is quite confusion,
> shouldnt it be "Request Terminated"? or I am doing something wrong
>
> On Tue, Apr 19, 2016 at 6:46 PM, Julian Santer 
> wrote:
>
>> Hi John,
>>
>> the commit was:
>>
>> commit 8133656de9503a122a72c0f80d11eff975bc43f1
>> Author: Bogdan-Andrei Iancu 
>> Date:   Thu Feb 11 14:58:41 2016 +0200
>>
>> Fix proper callig in local cancels with TH.
>>
>> Extend the coverage of the preocessing context and TM context over
>> the cancel_branch() function (in the timeout handler) so the TH callbacks
>> can reach back the dialog and do the TH related changes.
>> Reported by Julian Santer on mailing list.
>>
>> Kind regards,
>> Julian Santer
>> Raiffeisen OnLine
>>
>> Am 18.04.2016 um 22:35 schrieb John Nash:
>>
>>> which revision this was fixed?...I am also using OpenSips 2.1.2 and want
>>> to update only this change for the time being (2.2 has many changes)
>>>
>>> On Thu, Feb 11, 2016 at 7:19 PM, Julian Santer <
>>> julian.san...@rolmail.net >> julian.san...@rolmail.net>> wrote:
>>>
>>> Bogdan,
>>>
>>> we tried now the latest GIT release and it works like a charm ;-)
>>> Thank you for quick fix.
>>>
>>> Kind regards,
>>> Julian Santer
>>> Raiffeisen OnLine
>>>
>>> Am 11.02.2016 um 14:02 schrieb Bogdan-Andrei Iancu:
>>>
>>> Julian,
>>>
>>> Please update from GIT repo and give it a new try. It should
>>> work now (at least it does for me).
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>>
>>> On 11.02.2016 12:07, Julian Santer wrote:
>>>
>>> Hi Bogdan,
>>>
>>> thank you for your time. If you need further informations
>>> (config files etc.) let me know.
>>>
>>> Kind regards,
>>> Julian Santer
>>> Raiffeisen OnLine
>>>
>>> Am 11.02.2016 um 10:26 schrieb Bogdan-Andrei Iancu:
>>>
>>> Hi Julian,
>>>
>>> I will have to test this and come back to you.
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>>
>>> On 10.02.2016 17:45, Julian Santer wrote:
>>>
>>> Hi guys,
>>>
>>> we seem to got the same issue like John Nash on
>>> 2015/08/12.
>>> We use OpenSips 2.1.2 with the latest revision from
>>> git repo.
>>>
>>> Like John we are not sure if it is a bug or our
>>> mistake ;-)
>>>
>>> We are using topology hiding and the Call ID in the
>>> CANCEL, generated by the TM module, is not the same, as the call ID in the
>>> initial INVITE.
>>>
>>> The call flow looks like:
>>> PSTN carrier -> gw-carrier (topo hiding) -> core
>>> (topo hiding) -> gw-consumer (topo-hiding) -> UAC consumer
>>>
>>> The CANCEL generated by the TM module of the core,
>>> sended to the gw-consumer is rejected by the gw-consumer.
>>>
>>> The CANCEL starts on the core. So let me show you
>>> 1) the initial INVITE, which the core receives from
>>> the gw-carrier (Call-ID: GW-CARRIER)
>>> 2) the initial INVITE, which the core and sends to
>>> the gw-consumer (Call-ID: Core)
>>> 3) the CANCEL generated by the core after
>>> $T_fr_inv_timeout (Call-ID: GW-CARRIER)
>>>
>>> 1)
>>> INVITE sip:12345@IP_CORE SIP/2.0
>>> Via: SIP/2.0/UDP
>>> IP_GW-CARRIER:5060;branch=z9hG4bK6aa2.7710f555.0
>>> From: ;tag=E3AE5C5C-1A42
>>> To: