Re: [OpenSIPS-Users] newbie question -- anyone have OpenSIPS working with an AVAYA PBX?

[Iñaki Baz Castillo]

2010/3/19 Christian Vo :
> No experience with dialplan at this point, so I’m curious to know if anyone
> has OpenSIPS working with Avaya CM?
>
> If so, any generic config/ tips that can be shared?


OpenSIPS is a SIP proxy/registrar (along with other features). No
special config is required in order to work with SIP PBX's or
gateways. This is SIP protocol.

Perhaps if you could explain the exact problem you suffer...


-- 
Iñaki Baz Castillo


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

[OpenSIPS-Users] ACC extra variables

[Brad Bendy]

Hi List,

I ran into something interesting today (have not noticed this in the
past anyways).

We set a extra variable in the acc table for the gatewayId, we pull
these values from a memcache store, with some recent changes in our code
we now sometimes hit memcache twice for a gatewayId the second time is
always a different value (both are executed before we run we call
t_on_reply(), etc.

Now it is storing the 1st value and not the 2nd value in the acc table
it looks like as soon as the value is assigned that is the value that is
then stored in the acc table, has anyone else seen this and is this the
correct behavior? If so anyway to change it so the last value of the avp
is what is stored? When the avp value changes it's from the
memcache_fetch() call.

This on 1.6.2 I have not tried on other releases yet but will later on
tonight, we have done this same type of thing in the past and it has
appeared to work, but I will have to verify to make sure.

Thanks

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

Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

[Christian Vo]

Thanks Anca,

I think that's fixed the problem with smonitor,
I still can't add users though, 

Fatal error:  Call to undefined method MDB2_Error::execute() in 
/srv/www/htdocs/opensips-cp/web/tools/users/user_management/user_management.php 
on line 223,...

-Original Message-
From: Anca Vamanu [mailto:a...@opensips.org] 
Sent: Friday, March 19, 2010 2:41 PM
To: OpenSIPS users mailling list
Cc: Christian Vo
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

Forward from Alex:
---

Hi Christian,

Please check the following :
In the OpenSIPS config :
- if you have loaded the mi_fifo module;
loadmodule "mi_fifo.so"
- if you have declared the correct fifo parameters (if the fifo file 
name is the same as in Control Panel boxes config and if it has right 
permissions set);
- if I'm not wrong it should be something like this :
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
modparam("mi_fifo", "fifo_mode", 0666)

Leave the db.inc.php commented as it was before and please check the 
stuff above and let me know.

Regards,
Alex

---

Christian Vo wrote:
>
> Forgot to add:
>
> I had smonitor's db.inc.php settings uncommented,
>
> Now getting this error instead
>
> [Fri Mar 19 09:59:50 2010] [error] [client 172.18.53.97] PHP Fatal 
> error: Call to undefined method MDB2_Error::setFetchMode() in 
> /srv/www/htdocs/opensips-cp/web/tools/system/smonitor/lib/db_connect.php 
> on line 39, referer: http://10.32.0.97/cp/menu.php
>
> I'm very sure I installed pear and the related parts as per the 
> install guide..
>
> *From:* Christian Vo
> *Sent:* Friday, March 19, 2010 9:57 AM
> *To:* OpenSIPS users mailling list
> *Subject:* RE: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0
>
> Thx Alex,
>
> Confirming that these are my settings:
>
> // each server is a box
>
> $box_id=0;
>
> // mi host:port pair || fifo_file
>
> // $boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
>
> $boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";
>
> // monit host:port
>
> $boxes[$box_id]['monit']['conn']="127.0.0.1:2812";
>
> $boxes[$box_id]['monit']['user']="admin";
>
> $boxes[$box_id]['monit']['pass']="monit";
>
> $boxes[$box_id]['monit']['has_ssl']=0;
>
> // description (appears in mi , monit )
>
> $boxes[$box_id]['desc']="SIP server";
>
> At this point, Monit seems to be working, but Statistics Monitor 
> complains
>
> "Cannot connect to OpenSIPS Server via Management Interface 
> (127.0.0.1/8080)
>
> "
>
> *From:* users-boun...@lists.opensips.org 
> [mailto:users-boun...@lists.opensips.org] *On Behalf Of *Alex Ionescu
> *Sent:* Friday, March 19, 2010 1:42 AM
> *To:* OpenSIPS users mailling list
> *Subject:* Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0
>
> Hi Christian,
>
> Your boxes config must look like this :
>
> $box_id=0;
> // mi host:port pair || fifo_file
> //$boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
> //i guess you are using fifo, not xmlrpc so :
> $boxes[$box_id]['mi']['conn']="/tmp/opensips_proxy_fifo";
>
> // monit host:port => this is for monit to work ok
> $boxes[$box_id]['monit']['conn']="127.0.0.1:2812";
> //you must take the username and password from the monit config file 
> (monitrc).
> $boxes[$box_id]['monit']['user']="username";
> $boxes[$box_id]['monit']['pass']="password";
> // if you want to enable ssl
> $boxes[$box_id]['monit']['has_ssl']=1;
>
> Please re-check your config and let me know if it works now.
>
> Regards,
> Alex
>
> On 3/19/2010 01:42, Christian Vo wrote:
>
> New problem:
>
> So under opensips-cp/config/boxes.global.inc.php
>
> I changed the following:
>
> $boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
>
> (previously was $boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";"
>
> This seemed to resolve my issue with Systemà Monit
>
> However,
>
> System à Statistics Monitor , Systemà SIP Trace , System à MI 
> Commands, and System à Dispatcher all complain with the following 
> on-screen message
>
> "Cannot connect to OpenSIPS Server via Management Interface 
> (127.0.0.1/8080)"
>
> So I changed it back to
>
> $boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";
>
> But then
>
> I notice tools/monit/local.inc.php still doesn't contain any code..??
>
> *From:* users-boun...@lists.opensips.org 
>  
> [mailto:users-boun...@lists.opensips.org] *On Behalf Of *Christian Vo
> *Sent:* Thursday, March 18, 2010 10:21 AM
> *To:* OpenSIPS users mailling list
> *Subject:* Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0
>
> Thx for the notice, I've just downloaded and re-installed the lastest 
> 4.0 tarball.. (moved the old dir to backup, and replaced it with the 
> new, re-adjusting config parameters along the way.)
>
> Not sure if I missed something, but I'm getting this error on-screen now:
>
> Under the Systemà Monit tab
>
> I see "Primary Sip Server" 192.168.0.1:2812
>
> Followed by "I can't Connect"
>
> Something is wrong here, since I adjusted config/boxes.global.inc.php 
> so that my only entry 

Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

[Anca Vamanu]

Forward from Alex:
---

Hi Christian,

Please check the following :
In the OpenSIPS config :
- if you have loaded the mi_fifo module;
loadmodule "mi_fifo.so"
- if you have declared the correct fifo parameters (if the fifo file 
name is the same as in Control Panel boxes config and if it has right 
permissions set);
- if I'm not wrong it should be something like this :
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
modparam("mi_fifo", "fifo_mode", 0666)

Leave the db.inc.php commented as it was before and please check the 
stuff above and let me know.

Regards,
Alex

---

Christian Vo wrote:
>
> Forgot to add:
>
> I had smonitor’s db.inc.php settings uncommented,
>
> Now getting this error instead
>
> [Fri Mar 19 09:59:50 2010] [error] [client 172.18.53.97] PHP Fatal 
> error: Call to undefined method MDB2_Error::setFetchMode() in 
> /srv/www/htdocs/opensips-cp/web/tools/system/smonitor/lib/db_connect.php 
> on line 39, referer: http://10.32.0.97/cp/menu.php
>
> I’m very sure I installed pear and the related parts as per the 
> install guide..
>
> *From:* Christian Vo
> *Sent:* Friday, March 19, 2010 9:57 AM
> *To:* OpenSIPS users mailling list
> *Subject:* RE: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0
>
> Thx Alex,
>
> Confirming that these are my settings:
>
> // each server is a box
>
> $box_id=0;
>
> // mi host:port pair || fifo_file
>
> // $boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
>
> $boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";
>
> // monit host:port
>
> $boxes[$box_id]['monit']['conn']="127.0.0.1:2812";
>
> $boxes[$box_id]['monit']['user']="admin";
>
> $boxes[$box_id]['monit']['pass']="monit";
>
> $boxes[$box_id]['monit']['has_ssl']=0;
>
> // description (appears in mi , monit )
>
> $boxes[$box_id]['desc']="SIP server";
>
> At this point, Monit seems to be working, but Statistics Monitor 
> complains
>
> “Cannot connect to OpenSIPS Server via Management Interface 
> (127.0.0.1/8080)
>
> “
>
> *From:* users-boun...@lists.opensips.org 
> [mailto:users-boun...@lists.opensips.org] *On Behalf Of *Alex Ionescu
> *Sent:* Friday, March 19, 2010 1:42 AM
> *To:* OpenSIPS users mailling list
> *Subject:* Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0
>
> Hi Christian,
>
> Your boxes config must look like this :
>
> $box_id=0;
> // mi host:port pair || fifo_file
> //$boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
> //i guess you are using fifo, not xmlrpc so :
> $boxes[$box_id]['mi']['conn']="/tmp/opensips_proxy_fifo";
>
> // monit host:port => this is for monit to work ok
> $boxes[$box_id]['monit']['conn']="127.0.0.1:2812";
> //you must take the username and password from the monit config file 
> (monitrc).
> $boxes[$box_id]['monit']['user']="username";
> $boxes[$box_id]['monit']['pass']="password";
> // if you want to enable ssl
> $boxes[$box_id]['monit']['has_ssl']=1;
>
> Please re-check your config and let me know if it works now.
>
> Regards,
> Alex
>
> On 3/19/2010 01:42, Christian Vo wrote:
>
> New problem:
>
> So under opensips-cp/config/boxes.global.inc.php
>
> I changed the following:
>
> $boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
>
> (previously was $boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";”
>
> This seemed to resolve my issue with Systemà Monit
>
> However,
>
> System à Statistics Monitor , Systemà SIP Trace , System à MI 
> Commands, and System à Dispatcher all complain with the following 
> on-screen message
>
> “Cannot connect to OpenSIPS Server via Management Interface 
> (127.0.0.1/8080)”
>
> So I changed it back to
>
> $boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";
>
> But then
>
> I notice tools/monit/local.inc.php still doesn’t contain any code….??
>
> *From:* users-boun...@lists.opensips.org 
>  
> [mailto:users-boun...@lists.opensips.org] *On Behalf Of *Christian Vo
> *Sent:* Thursday, March 18, 2010 10:21 AM
> *To:* OpenSIPS users mailling list
> *Subject:* Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0
>
> Thx for the notice, I’ve just downloaded and re-installed the lastest 
> 4.0 tarball…. (moved the old dir to backup, and replaced it with the 
> new, re-adjusting config parameters along the way…)
>
> Not sure if I missed something, but I’m getting this error on-screen now:
>
> Under the Systemà Monit tab
>
> I see “Primary Sip Server” 192.168.0.1:2812
>
> Followed by “I can’t Connect”
>
> Something is wrong here, since I adjusted config/boxes.global.inc.php 
> so that my only entry (Primary SIP Server) would be using 
> 127.0.0.1:2812 for monit
>
> And I don’t know where else I’d find any entry for 192.168.0.1 related 
> to this..
>
> This part was working for me back when I had the previous 4.0 tarball… odd
>
> *From:* users-boun...@lists.opensips.org 
>  
> [mailto:users-boun...@lists.opensips.org] *On Behalf Of *Alex Ionescu
> *Sent:* Thursday, March 18, 2010 4:46 AM
> *To:* OpenSIPS users mailling list
> *Subject:* Re:

Re: [OpenSIPS-Users] how to implement call forward after 486 (busy) with 181 message

[Daniel Ribeiro]

Unfortunately my scenario still doens't working because the target number
answer with 482 loop detection. I think ti happens because CallID that is
the same of the first INVITE or because we have the same address of proxy
twice for Record-Route and Via.
Did you know something about that?
Thanks

Record-Route: 
Record-Route: 
Date: Fri, 19 Mar 2010 20:53:37 GMT
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.1.200;branch=z9hG4bK1982.91a86915.0
Via: SIP/2.0/UDP 192.168.1.200;branch=z9hG4bK1982.81a86915.1
Via: SIP/2.0/UDP 192.168.1.200:5082
;received=192.168.1.200;branch=z9hG4bKeaa4d328-0732-df11-91ee-002421899f1c;rport=5082
User-Agent: Ekiga/2.0.12
From: "101816" 
>;tag=8cc7d228-0732-df11-91ee-002421899f1c
Call-ID: c6c4d228-0732-df11-91ee-002421899...@danielribeiro
To: >
Contact: 
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE
Content-Type: application/sdp
Content-Length: 279
Max-Forwards: 68



On Fri, Mar 19, 2010 at 5:56 PM, Brett Nemeroff  wrote:

> Great! glad it's working for you.
> -Brett
>
>
> On Fri, Mar 19, 2010 at 3:54 PM, Daniel Ribeiro  > wrote:
>
>> Correction... t_reply - t_reply("181","Call Is Being Forwarded"); - works
>> fine.
>> I made a mistake and collect packets at the wrong interface.
>> Thanks Brett.
>>
>>
>>
>>
>> On Fri, Mar 19, 2010 at 4:24 PM, Daniel Ribeiro <
>> ribeiro.dani...@gmail.com> wrote:
>>
>>> I collect the sip messages at wireshark.
>>>
>>> No. TimeSourceDestination   Protocol
>>> Info
>>>   3 0.090288192.168.1.200 192.168.1.2   SIP/SDP
>>> Request: INVITE sip:1...@192.168.1.2 , with session
>>> description
>>>
>>>   4 0.132793192.168.1.2   192.168.1.200 SIP
>>> Status: 100 Trying
>>>   5 0.142907192.168.1.2   192.168.1.200 SIP
>>> Status: 486 Busy Here
>>>   6 0.143218192.168.1.200 192.168.1.2   SIP
>>> Request: ACK sip:1...@192.168.1.2 
>>>   7 0.145198192.168.1.200 192.168.1.2   SIP/SDP
>>> Request: INVITE sip:1...@192.168.1.2 , with session
>>> description
>>>
>>>   8 0.165471192.168.1.2   192.168.1.200 SIP
>>> Status: 482 Loop Detected
>>>9 0.166064192.168.1.200 192.168.1.2   SIP
>>> Request: ACK sip:1...@192.168.1.2 
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 19, 2010 at 4:16 PM, Brett Nemeroff wrote:
>>>
 Your log wouldn't show if it worked or not.. have you watched a sip
 trace?

 Thanks,
 Brett


 On Fri, Mar 19, 2010 at 12:54 PM, Daniel Ribeiro <
 ribeiro.dani...@gmail.com> wrote:

> I try that but don't work.
>
>
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new
> branch at sip:1...@192.168.1.2 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
> invite
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
> invite
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply error 486
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC:
> call missed:
> timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
> 72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=486;reason=Busy
> Here
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: Redirect
> busy calls
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: before
> revert sip:1...@192.168.1.2 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: after
> revert sip:1...@192.168.1.200 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]:
> forwarded to: sip:1...@192.168.1.200 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new
> branch at sip:1...@192.168.1.200 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new
> branch at sip:1...@192.168.1.2 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
> invite
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
> invite
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC:
> call missed:
> timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
> 72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=482;reason=Loop
> Detected
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>>>

Re: [OpenSIPS-Users] how to implement call forward after 486 (busy) with 181 message

[Brett Nemeroff]

Great! glad it's working for you.
-Brett


On Fri, Mar 19, 2010 at 3:54 PM, Daniel Ribeiro
wrote:

> Correction... t_reply - t_reply("181","Call Is Being Forwarded"); - works
> fine.
> I made a mistake and collect packets at the wrong interface.
> Thanks Brett.
>
>
>
>
> On Fri, Mar 19, 2010 at 4:24 PM, Daniel Ribeiro  > wrote:
>
>> I collect the sip messages at wireshark.
>>
>> No. TimeSourceDestination   Protocol
>> Info
>>   3 0.090288192.168.1.200 192.168.1.2   SIP/SDP
>> Request: INVITE sip:1...@192.168.1.2 , with session
>> description
>>
>>   4 0.132793192.168.1.2   192.168.1.200 SIP
>> Status: 100 Trying
>>   5 0.142907192.168.1.2   192.168.1.200 SIP
>> Status: 486 Busy Here
>>   6 0.143218192.168.1.200 192.168.1.2   SIP
>> Request: ACK sip:1...@192.168.1.2 
>>   7 0.145198192.168.1.200 192.168.1.2   SIP/SDP
>> Request: INVITE sip:1...@192.168.1.2 , with session
>> description
>>
>>   8 0.165471192.168.1.2   192.168.1.200 SIP
>> Status: 482 Loop Detected
>>9 0.166064192.168.1.200 192.168.1.2   SIP
>> Request: ACK sip:1...@192.168.1.2 
>>
>>
>>
>>
>>
>> On Fri, Mar 19, 2010 at 4:16 PM, Brett Nemeroff wrote:
>>
>>> Your log wouldn't show if it worked or not.. have you watched a sip
>>> trace?
>>>
>>> Thanks,
>>> Brett
>>>
>>>
>>> On Fri, Mar 19, 2010 at 12:54 PM, Daniel Ribeiro <
>>> ribeiro.dani...@gmail.com> wrote:
>>>
 I try that but don't work.


 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new
 branch at sip:1...@192.168.1.2 
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
 reply
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
 invite
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
 reply
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
 invite
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
 reply error 486
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC: call
 missed:
 timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
 72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=486;reason=Busy
 Here
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: Redirect
 busy calls
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: before
 revert sip:1...@192.168.1.2 
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: after
 revert sip:1...@192.168.1.200 
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: forwarded
 to: sip:1...@192.168.1.200 
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new
 branch at sip:1...@192.168.1.200 
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new
 branch at sip:1...@192.168.1.2 
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
 reply
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
 invite
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
 reply
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
 invite
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC: call
 missed:
 timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
 72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=482;reason=Loop
 Detected
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
 reply
 Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
 invite


 On Fri, Mar 19, 2010 at 2:17 PM, Brett Nemeroff wrote:

> Oh, right.. failure routes don't make sense in stateless. maybe t_reply
> then?
> t_reply("181","Call Is Being Forwarded")
> ??
> -brett
>
>
> On Fri, Mar 19, 2010 at 12:13 PM, Daniel Ribeiro <
> ribeiro.dani...@gmail.com> wrote:
>
>> This method isn't permitted at failure_route.
>>
>>
>>
>> On Fri, Mar 19, 2010 at 2:11 PM, Daniel Ribeiro <
>> ribeiro.dani...@gmail.com> wrote:
>>
>>> One more detail...
>>> I'm trying to implement this scenario.
>>> http://www.tech-invite.com/Ti-sip-service-8.html#fig4
>>>
>>>
>>>
>>> On Fri, Mar 19, 2010 at 2:05 PM, Daniel Ribeiro <
>>> ribeiro.dani...@gmail.com> wrote:
>>>
 Hello guys,

 I'm trying to implement the call forward after a busy message
 following some internet examples but without success.
 How can I generate an 181 message after a error 486.
 I'm trying with this cfg for failure_route.

 fai

Re: [OpenSIPS-Users] how to implement call forward after 486 (busy) with 181 message

[Daniel Ribeiro]

Correction... t_reply - t_reply("181","Call Is Being Forwarded"); - works
fine.
I made a mistake and collect packets at the wrong interface.
Thanks Brett.



On Fri, Mar 19, 2010 at 4:24 PM, Daniel Ribeiro
wrote:

> I collect the sip messages at wireshark.
>
> No. TimeSourceDestination   Protocol
> Info
>   3 0.090288192.168.1.200 192.168.1.2   SIP/SDP
> Request: INVITE sip:1...@192.168.1.2 , with session
> description
>
>   4 0.132793192.168.1.2   192.168.1.200 SIP
> Status: 100 Trying
>   5 0.142907192.168.1.2   192.168.1.200 SIP
> Status: 486 Busy Here
>   6 0.143218192.168.1.200 192.168.1.2   SIP
> Request: ACK sip:1...@192.168.1.2 
>   7 0.145198192.168.1.200 192.168.1.2   SIP/SDP
> Request: INVITE sip:1...@192.168.1.2 , with session
> description
>
>   8 0.165471192.168.1.2   192.168.1.200 SIP
> Status: 482 Loop Detected
>   9 0.166064192.168.1.200 192.168.1.2   SIP
> Request: ACK sip:1...@192.168.1.2 
>
>
>
>
>
> On Fri, Mar 19, 2010 at 4:16 PM, Brett Nemeroff wrote:
>
>> Your log wouldn't show if it worked or not.. have you watched a sip trace?
>>
>> Thanks,
>> Brett
>>
>>
>> On Fri, Mar 19, 2010 at 12:54 PM, Daniel Ribeiro <
>> ribeiro.dani...@gmail.com> wrote:
>>
>>> I try that but don't work.
>>>
>>>
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch
>>> at sip:1...@192.168.1.2 
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>>> reply
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>>> invite
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>>> reply
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>>> invite
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>>> reply error 486
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC: call
>>> missed:
>>> timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
>>> 72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=486;reason=Busy
>>> Here
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: Redirect
>>> busy calls
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: before
>>> revert sip:1...@192.168.1.2 
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: after
>>> revert sip:1...@192.168.1.200 
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: forwarded
>>> to: sip:1...@192.168.1.200 
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch
>>> at sip:1...@192.168.1.200 
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch
>>> at sip:1...@192.168.1.2 
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>>> reply
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>>> invite
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>>> reply
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>>> invite
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC: call
>>> missed:
>>> timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
>>> 72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=482;reason=Loop
>>> Detected
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>>> reply
>>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>>> invite
>>>
>>>
>>> On Fri, Mar 19, 2010 at 2:17 PM, Brett Nemeroff wrote:
>>>
 Oh, right.. failure routes don't make sense in stateless. maybe t_reply
 then?
 t_reply("181","Call Is Being Forwarded")
 ??
 -brett


 On Fri, Mar 19, 2010 at 12:13 PM, Daniel Ribeiro <
 ribeiro.dani...@gmail.com> wrote:

> This method isn't permitted at failure_route.
>
>
>
> On Fri, Mar 19, 2010 at 2:11 PM, Daniel Ribeiro <
> ribeiro.dani...@gmail.com> wrote:
>
>> One more detail...
>> I'm trying to implement this scenario.
>> http://www.tech-invite.com/Ti-sip-service-8.html#fig4
>>
>>
>>
>> On Fri, Mar 19, 2010 at 2:05 PM, Daniel Ribeiro <
>> ribeiro.dani...@gmail.com> wrote:
>>
>>> Hello guys,
>>>
>>> I'm trying to implement the call forward after a busy message
>>> following some internet examples but without success.
>>> How can I generate an 181 message after a error 486.
>>> I'm trying with this cfg for failure_route.
>>>
>>> failure_route[1] {
>>> if (t_was_cancelled()) {
>>> exit;
>>> }
>>>
>>> # uncomment the following lines if you want to block client
>>> # redirect based on 3xx replies.
>>> ##if (t_check_status("

Re: [OpenSIPS-Users] how to implement call forward after 486 (busy) with 181 message

[Daniel Ribeiro]

I collect the sip messages at wireshark.
No. TimeSourceDestination   Protocol
Info
  3 0.090288192.168.1.200 192.168.1.2   SIP/SDP
Request: INVITE sip:1...@192.168.1.2 , with session
description
  4 0.132793192.168.1.2   192.168.1.200 SIP
Status: 100 Trying
  5 0.142907192.168.1.2   192.168.1.200 SIP
Status: 486 Busy Here
  6 0.143218192.168.1.200 192.168.1.2   SIP
Request: ACK sip:1...@192.168.1.2 
  7 0.145198192.168.1.200 192.168.1.2   SIP/SDP
Request: INVITE sip:1...@192.168.1.2 , with session
description
  8 0.165471192.168.1.2   192.168.1.200 SIP
Status: 482 Loop Detected
  9 0.166064192.168.1.200 192.168.1.2   SIP
Request: ACK sip:1...@192.168.1.2 




On Fri, Mar 19, 2010 at 4:16 PM, Brett Nemeroff  wrote:

> Your log wouldn't show if it worked or not.. have you watched a sip trace?
>
> Thanks,
> Brett
>
>
> On Fri, Mar 19, 2010 at 12:54 PM, Daniel Ribeiro <
> ribeiro.dani...@gmail.com> wrote:
>
>> I try that but don't work.
>>
>>
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch
>> at sip:1...@192.168.1.2 
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>> reply
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>> invite
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>> reply
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>> invite
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>> reply error 486
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC: call
>> missed:
>> timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
>> 72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=486;reason=Busy
>> Here
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: Redirect
>> busy calls
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: before
>> revert sip:1...@192.168.1.2 
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: after
>> revert sip:1...@192.168.1.200 
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: forwarded
>> to: sip:1...@192.168.1.200 
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch
>> at sip:1...@192.168.1.200 
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch
>> at sip:1...@192.168.1.2 
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>> reply
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>> invite
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>> reply
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>> invite
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC: call
>> missed:
>> timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
>> 72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=482;reason=Loop
>> Detected
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
>> reply
>> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
>> invite
>>
>>
>> On Fri, Mar 19, 2010 at 2:17 PM, Brett Nemeroff wrote:
>>
>>> Oh, right.. failure routes don't make sense in stateless. maybe t_reply
>>> then?
>>> t_reply("181","Call Is Being Forwarded")
>>> ??
>>> -brett
>>>
>>>
>>> On Fri, Mar 19, 2010 at 12:13 PM, Daniel Ribeiro <
>>> ribeiro.dani...@gmail.com> wrote:
>>>
 This method isn't permitted at failure_route.



 On Fri, Mar 19, 2010 at 2:11 PM, Daniel Ribeiro <
 ribeiro.dani...@gmail.com> wrote:

> One more detail...
> I'm trying to implement this scenario.
> http://www.tech-invite.com/Ti-sip-service-8.html#fig4
>
>
>
> On Fri, Mar 19, 2010 at 2:05 PM, Daniel Ribeiro <
> ribeiro.dani...@gmail.com> wrote:
>
>> Hello guys,
>>
>> I'm trying to implement the call forward after a busy message
>> following some internet examples but without success.
>> How can I generate an 181 message after a error 486.
>> I'm trying with this cfg for failure_route.
>>
>> failure_route[1] {
>> if (t_was_cancelled()) {
>> exit;
>> }
>>
>> # uncomment the following lines if you want to block client
>> # redirect based on 3xx replies.
>> ##if (t_check_status("3[0-9][0-9]")) {
>> ##t_reply("404","Not found");
>> ##exit;
>> ##}
>>
>> # Redirect busy calls to another destination
>> if (t_check_status("486")) {
>> xlog("Redirect busy calls\n");
>> xlog("before revert $ru\n");
>> revert_uri();
>> xlog("after revert $ru\n");
>>  

Re: [OpenSIPS-Users] how to implement call forward after 486 (busy) with 181 message

[Brett Nemeroff]

Your log wouldn't show if it worked or not.. have you watched a sip trace?

Thanks,
Brett


On Fri, Mar 19, 2010 at 12:54 PM, Daniel Ribeiro
wrote:

> I try that but don't work.
>
>
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch
> at sip:1...@192.168.1.2 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
> invite
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
> invite
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply error 486
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC: call
> missed:
> timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
> 72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=486;reason=Busy
> Here
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: Redirect
> busy calls
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: before
> revert sip:1...@192.168.1.2 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: after revert
> sip:1...@192.168.1.200 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: forwarded
> to: sip:1...@192.168.1.200 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch
> at sip:1...@192.168.1.200 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch
> at sip:1...@192.168.1.2 
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
> invite
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
> invite
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC: call
> missed:
> timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
> 72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=482;reason=Loop
> Detected
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
> reply
> Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
> invite
>
>
> On Fri, Mar 19, 2010 at 2:17 PM, Brett Nemeroff wrote:
>
>> Oh, right.. failure routes don't make sense in stateless. maybe t_reply
>> then?
>> t_reply("181","Call Is Being Forwarded")
>> ??
>> -brett
>>
>>
>> On Fri, Mar 19, 2010 at 12:13 PM, Daniel Ribeiro <
>> ribeiro.dani...@gmail.com> wrote:
>>
>>> This method isn't permitted at failure_route.
>>>
>>>
>>>
>>> On Fri, Mar 19, 2010 at 2:11 PM, Daniel Ribeiro <
>>> ribeiro.dani...@gmail.com> wrote:
>>>
 One more detail...
 I'm trying to implement this scenario.
 http://www.tech-invite.com/Ti-sip-service-8.html#fig4



 On Fri, Mar 19, 2010 at 2:05 PM, Daniel Ribeiro <
 ribeiro.dani...@gmail.com> wrote:

> Hello guys,
>
> I'm trying to implement the call forward after a busy message following
> some internet examples but without success.
> How can I generate an 181 message after a error 486.
> I'm trying with this cfg for failure_route.
>
> failure_route[1] {
> if (t_was_cancelled()) {
> exit;
> }
>
> # uncomment the following lines if you want to block client
> # redirect based on 3xx replies.
> ##if (t_check_status("3[0-9][0-9]")) {
> ##t_reply("404","Not found");
> ##exit;
> ##}
>
> # Redirect busy calls to another destination
> if (t_check_status("486")) {
> xlog("Redirect busy calls\n");
> xlog("before revert $ru\n");
> revert_uri();
> xlog("after revert $ru\n");
> #If there is an AVP called fwdbusy send to it
> if(avp_db_load("$ru","$avp(s:fwdbusy)")) {
> $ru = $avp(s:fwdbusy);
> xlog("forwarded to: $ru");
> }
> t_relay();
> }
> }
>
>
> The log output was:
> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: new
> branch at sip:1...@192.168.1.2 
> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC:
> transaction answered:
> timestamp=1269016498;me

[OpenSIPS-Users] newbie question -- anyone have OpenSIPS working with an AVAYA PBX?

[Christian Vo]

At this point, I can make basic SIP calls (i.e. xlite to xlite) =)

No experience with dialplan at this point, so I'm curious to know if anyone has 
OpenSIPS working with Avaya CM?
If so, any generic config/ tips that can be shared?

Thx



---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Error in module permission with db_text

[Daniel Ribeiro]

Hi,

It means that your table my have invalid fields. I don't know why but when
fileds are invalid the error say table doens't exist.
An table example could be:

id(int,auto) uuid(string) username(string) domain(string) attribute(string)
type(int) value(string) last_modified(int)
2:11fwdb:11:192.168.1.200:fwdbusy:0:sip\:1...@192.168.1.200:0
3:11fwdna:11:192.168.1.200:fwdnoansw:0:sip\:1...@192.168.1.200:0


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

Re: [OpenSIPS-Users] how to implement call forward after 486 (busy) with 181 message

[Daniel Ribeiro]

I try that but don't work.


Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch at
sip:1...@192.168.1.2 
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
reply
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
invite
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
reply
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
invite
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
reply error 486
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC: call
missed:
timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=486;reason=Busy Here

Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: Redirect busy
calls
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: before revert
sip:1...@192.168.1.2 
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: after revert
sip:1...@192.168.1.200 
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: forwarded to:
sip:1...@192.168.1.200 
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch at
sip:1...@192.168.1.200 
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: new branch at
sip:1...@192.168.1.2 
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
reply
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
invite
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
reply
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
invite
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: ACC: call
missed:
timestamp=1269021181;method=INVITE;from_tag=1744708490;to_tag=192.168.1.2+1+108+b729333f;call_id=
72768d14-a5db-edcd-dd18-c6cfb4ead...@192.168.1.200;code=482;reason=Loop
Detected
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: incoming
reply
Mar 19 14:53:01 danielribeiro /usr/local/sbin/opensips[26630]: onreply
invite


On Fri, Mar 19, 2010 at 2:17 PM, Brett Nemeroff  wrote:

> Oh, right.. failure routes don't make sense in stateless. maybe t_reply
> then?
> t_reply("181","Call Is Being Forwarded")
> ??
> -brett
>
>
> On Fri, Mar 19, 2010 at 12:13 PM, Daniel Ribeiro <
> ribeiro.dani...@gmail.com> wrote:
>
>> This method isn't permitted at failure_route.
>>
>>
>>
>> On Fri, Mar 19, 2010 at 2:11 PM, Daniel Ribeiro <
>> ribeiro.dani...@gmail.com> wrote:
>>
>>> One more detail...
>>> I'm trying to implement this scenario.
>>> http://www.tech-invite.com/Ti-sip-service-8.html#fig4
>>>
>>>
>>>
>>> On Fri, Mar 19, 2010 at 2:05 PM, Daniel Ribeiro <
>>> ribeiro.dani...@gmail.com> wrote:
>>>
 Hello guys,

 I'm trying to implement the call forward after a busy message following
 some internet examples but without success.
 How can I generate an 181 message after a error 486.
 I'm trying with this cfg for failure_route.

 failure_route[1] {
 if (t_was_cancelled()) {
 exit;
 }

 # uncomment the following lines if you want to block client
 # redirect based on 3xx replies.
 ##if (t_check_status("3[0-9][0-9]")) {
 ##t_reply("404","Not found");
 ##exit;
 ##}

 # Redirect busy calls to another destination
 if (t_check_status("486")) {
 xlog("Redirect busy calls\n");
 xlog("before revert $ru\n");
 revert_uri();
 xlog("after revert $ru\n");
 #If there is an AVP called fwdbusy send to it
 if(avp_db_load("$ru","$avp(s:fwdbusy)")) {
 $ru = $avp(s:fwdbusy);
 xlog("forwarded to: $ru");
 }
 t_relay();
 }
 }


 The log output was:
 Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: new
 branch at sip:1...@192.168.1.2 
 Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: incoming
 reply
 Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: onreply
 invite
 Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: incoming
 reply
 Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: onreply
 invite
 Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: incoming
 reply
 Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: onreply
 invite
 Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC:
 transaction answered:
 timestamp=1269016498;method=INVITE;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
 3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
 Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC:
 request acknowledged:
 timestamp=1269016498;method=ACK;from_tag=286496395;to_tag=192.168.1.2

Re: [OpenSIPS-Users] how to implement call forward after 486 (busy) with 181 message

[Brett Nemeroff]

Oh, right.. failure routes don't make sense in stateless. maybe t_reply
then?
t_reply("181","Call Is Being Forwarded")
??
-brett


On Fri, Mar 19, 2010 at 12:13 PM, Daniel Ribeiro
wrote:

> This method isn't permitted at failure_route.
>
>
>
> On Fri, Mar 19, 2010 at 2:11 PM, Daniel Ribeiro  > wrote:
>
>> One more detail...
>> I'm trying to implement this scenario.
>> http://www.tech-invite.com/Ti-sip-service-8.html#fig4
>>
>>
>>
>> On Fri, Mar 19, 2010 at 2:05 PM, Daniel Ribeiro <
>> ribeiro.dani...@gmail.com> wrote:
>>
>>> Hello guys,
>>>
>>> I'm trying to implement the call forward after a busy message following
>>> some internet examples but without success.
>>> How can I generate an 181 message after a error 486.
>>> I'm trying with this cfg for failure_route.
>>>
>>> failure_route[1] {
>>> if (t_was_cancelled()) {
>>> exit;
>>> }
>>>
>>> # uncomment the following lines if you want to block client
>>> # redirect based on 3xx replies.
>>> ##if (t_check_status("3[0-9][0-9]")) {
>>> ##t_reply("404","Not found");
>>> ##exit;
>>> ##}
>>>
>>> # Redirect busy calls to another destination
>>> if (t_check_status("486")) {
>>> xlog("Redirect busy calls\n");
>>> xlog("before revert $ru\n");
>>> revert_uri();
>>> xlog("after revert $ru\n");
>>> #If there is an AVP called fwdbusy send to it
>>> if(avp_db_load("$ru","$avp(s:fwdbusy)")) {
>>> $ru = $avp(s:fwdbusy);
>>> xlog("forwarded to: $ru");
>>> }
>>> t_relay();
>>> }
>>> }
>>>
>>>
>>> The log output was:
>>> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: new branch
>>> at sip:1...@192.168.1.2 
>>> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>>> reply
>>> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>>> invite
>>> Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>>> reply
>>> Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>>> invite
>>> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>>> reply
>>> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>>> invite
>>> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC:
>>> transaction answered:
>>> timestamp=1269016498;method=INVITE;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
>>> 3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
>>> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC:
>>> request acknowledged:
>>> timestamp=1269016498;method=ACK;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
>>> 3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
>>> at sip:1...@192.168.1.2 
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>>> reply
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>>> invite
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>>> reply
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>>> invite
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>>> reply error 486
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: ACC: call
>>> missed:
>>> timestamp=1269016500;method=INVITE;from_tag=c298fc07-e331-df11-91ee-002421899f1c;to_tag=192.168.1.2+1+108+b729333f;call_id=fc95fc07-e331-df11-91ee-002421899...@danielribeiro;code=486;reason=Busy
>>> Here
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: Redirect
>>> busy calls
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: before
>>> revert sip:1...@192.168.1.2 
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: after
>>> revert sip:1...@192.168.1.200 
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: forwarded
>>> to: sip:1...@192.168.1.200 
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
>>> at sip:1...@192.168.1.200 
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
>>> at sip:1...@192.168.1.2 
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>>> reply
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>>> invite
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>>> reply
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>>> invite
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: ACC: call
>>> missed:
>>> timestamp=1269016500;method=INVITE;from_tag=c298fc07-e331-df11-91ee-002421899f1c;to_tag=192.168.1.2+1+108+b729333f;call_id=fc95fc07-e331-df11-91ee-002421899...@xxx;code=482;reason=Loop
>>> Detected
>>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>>> reply

Re: [OpenSIPS-Users] how to implement call forward after 486 (busy) with 181 message

[Daniel Ribeiro]

This method isn't permitted at failure_route.


On Fri, Mar 19, 2010 at 2:11 PM, Daniel Ribeiro
wrote:

> One more detail...
> I'm trying to implement this scenario.
> http://www.tech-invite.com/Ti-sip-service-8.html#fig4
>
>
>
> On Fri, Mar 19, 2010 at 2:05 PM, Daniel Ribeiro  > wrote:
>
>> Hello guys,
>>
>> I'm trying to implement the call forward after a busy message following
>> some internet examples but without success.
>> How can I generate an 181 message after a error 486.
>> I'm trying with this cfg for failure_route.
>>
>> failure_route[1] {
>> if (t_was_cancelled()) {
>> exit;
>> }
>>
>> # uncomment the following lines if you want to block client
>> # redirect based on 3xx replies.
>> ##if (t_check_status("3[0-9][0-9]")) {
>> ##t_reply("404","Not found");
>> ##exit;
>> ##}
>>
>> # Redirect busy calls to another destination
>> if (t_check_status("486")) {
>> xlog("Redirect busy calls\n");
>> xlog("before revert $ru\n");
>> revert_uri();
>> xlog("after revert $ru\n");
>> #If there is an AVP called fwdbusy send to it
>> if(avp_db_load("$ru","$avp(s:fwdbusy)")) {
>> $ru = $avp(s:fwdbusy);
>> xlog("forwarded to: $ru");
>> }
>> t_relay();
>> }
>> }
>>
>>
>> The log output was:
>> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: new branch
>> at sip:1...@192.168.1.2 
>> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>> reply
>> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>> invite
>> Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>> reply
>> Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>> invite
>> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>> reply
>> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>> invite
>> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC:
>> transaction answered:
>> timestamp=1269016498;method=INVITE;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
>> 3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
>> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC:
>> request acknowledged:
>> timestamp=1269016498;method=ACK;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
>> 3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
>> at sip:1...@192.168.1.2 
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>> reply
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>> invite
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>> reply
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>> invite
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>> reply error 486
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: ACC: call
>> missed:
>> timestamp=1269016500;method=INVITE;from_tag=c298fc07-e331-df11-91ee-002421899f1c;to_tag=192.168.1.2+1+108+b729333f;call_id=fc95fc07-e331-df11-91ee-002421899...@danielribeiro;code=486;reason=Busy
>> Here
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: Redirect
>> busy calls
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: before
>> revert sip:1...@192.168.1.2 
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: after
>> revert sip:1...@192.168.1.200 
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: forwarded
>> to: sip:1...@192.168.1.200 
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
>> at sip:1...@192.168.1.200 
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
>> at sip:1...@192.168.1.2 
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>> reply
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>> invite
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>> reply
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>> invite
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: ACC: call
>> missed:
>> timestamp=1269016500;method=INVITE;from_tag=c298fc07-e331-df11-91ee-002421899f1c;to_tag=192.168.1.2+1+108+b729333f;call_id=fc95fc07-e331-df11-91ee-002421899...@xxx;code=482;reason=Loop
>> Detected
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
>> reply
>> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
>> invite
>>
>>
>> --
>> Daniel Ribeiro
>>
>
>
>
> --
> Daniel Ribeiro
>



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

Re: [OpenSIPS-Users] how to implement call forward after 486 (busy) with 181 message

[Brett Nemeroff]

Well what you've posted will just redirect the call.. you'd never know it
was redirected really.

If you want you can send a:
sl_send_reply("181","Call Is Being Forwarded")
before you t_relay.. i think that will work.. Let us know..
-Brett


On Fri, Mar 19, 2010 at 12:05 PM, Daniel Ribeiro
wrote:

> Hello guys,
>
> I'm trying to implement the call forward after a busy message following
> some internet examples but without success.
> How can I generate an 181 message after a error 486.
> I'm trying with this cfg for failure_route.
>
> failure_route[1] {
> if (t_was_cancelled()) {
> exit;
> }
>
> # uncomment the following lines if you want to block client
> # redirect based on 3xx replies.
> ##if (t_check_status("3[0-9][0-9]")) {
> ##t_reply("404","Not found");
> ##exit;
> ##}
>
> # Redirect busy calls to another destination
> if (t_check_status("486")) {
> xlog("Redirect busy calls\n");
> xlog("before revert $ru\n");
> revert_uri();
> xlog("after revert $ru\n");
> #If there is an AVP called fwdbusy send to it
> if(avp_db_load("$ru","$avp(s:fwdbusy)")) {
> $ru = $avp(s:fwdbusy);
> xlog("forwarded to: $ru");
> }
> t_relay();
> }
> }
>
>
> The log output was:
> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: new branch
> at sip:1...@192.168.1.2 
> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC:
> transaction answered:
> timestamp=1269016498;method=INVITE;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
> 3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC: request
> acknowledged:
> timestamp=1269016498;method=ACK;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
> 3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
> at sip:1...@192.168.1.2 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply error 486
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: ACC: call
> missed:
> timestamp=1269016500;method=INVITE;from_tag=c298fc07-e331-df11-91ee-002421899f1c;to_tag=192.168.1.2+1+108+b729333f;call_id=fc95fc07-e331-df11-91ee-002421899...@danielribeiro;code=486;reason=Busy
> Here
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: Redirect
> busy calls
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: before
> revert sip:1...@192.168.1.2 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: after revert
> sip:1...@192.168.1.200 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: forwarded
> to: sip:1...@192.168.1.200 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
> at sip:1...@192.168.1.200 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
> at sip:1...@192.168.1.2 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: ACC: call
> missed:
> timestamp=1269016500;method=INVITE;from_tag=c298fc07-e331-df11-91ee-002421899f1c;to_tag=192.168.1.2+1+108+b729333f;call_id=fc95fc07-e331-df11-91ee-002421899...@xxx;code=482;reason=Loop
> Detected
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
>
>
> --
> Daniel Ribeiro
>
> ___
> 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] how to implement call forward after 486 (busy) with 181 message

[Daniel Ribeiro]

One more detail...
I'm trying to implement this scenario.
http://www.tech-invite.com/Ti-sip-service-8.html#fig4


On Fri, Mar 19, 2010 at 2:05 PM, Daniel Ribeiro
wrote:

> Hello guys,
>
> I'm trying to implement the call forward after a busy message following
> some internet examples but without success.
> How can I generate an 181 message after a error 486.
> I'm trying with this cfg for failure_route.
>
> failure_route[1] {
> if (t_was_cancelled()) {
> exit;
> }
>
> # uncomment the following lines if you want to block client
> # redirect based on 3xx replies.
> ##if (t_check_status("3[0-9][0-9]")) {
> ##t_reply("404","Not found");
> ##exit;
> ##}
>
> # Redirect busy calls to another destination
> if (t_check_status("486")) {
> xlog("Redirect busy calls\n");
> xlog("before revert $ru\n");
> revert_uri();
> xlog("after revert $ru\n");
> #If there is an AVP called fwdbusy send to it
> if(avp_db_load("$ru","$avp(s:fwdbusy)")) {
> $ru = $avp(s:fwdbusy);
> xlog("forwarded to: $ru");
> }
> t_relay();
> }
> }
>
>
> The log output was:
> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: new branch
> at sip:1...@192.168.1.2 
> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC:
> transaction answered:
> timestamp=1269016498;method=INVITE;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
> 3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
> Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC: request
> acknowledged:
> timestamp=1269016498;method=ACK;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
> 3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
> at sip:1...@192.168.1.2 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply error 486
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: ACC: call
> missed:
> timestamp=1269016500;method=INVITE;from_tag=c298fc07-e331-df11-91ee-002421899f1c;to_tag=192.168.1.2+1+108+b729333f;call_id=fc95fc07-e331-df11-91ee-002421899...@danielribeiro;code=486;reason=Busy
> Here
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: Redirect
> busy calls
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: before
> revert sip:1...@192.168.1.2 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: after revert
> sip:1...@192.168.1.200 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: forwarded
> to: sip:1...@192.168.1.200 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
> at sip:1...@192.168.1.200 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch
> at sip:1...@192.168.1.2 
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: ACC: call
> missed:
> timestamp=1269016500;method=INVITE;from_tag=c298fc07-e331-df11-91ee-002421899f1c;to_tag=192.168.1.2+1+108+b729333f;call_id=fc95fc07-e331-df11-91ee-002421899...@xxx;code=482;reason=Loop
> Detected
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
> reply
> Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
> invite
>
>
> --
> Daniel Ribeiro
>



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

[OpenSIPS-Users] how to implement call forward after 486 (busy) with 181 message

[Daniel Ribeiro]

Hello guys,

I'm trying to implement the call forward after a busy message following some
internet examples but without success.
How can I generate an 181 message after a error 486.
I'm trying with this cfg for failure_route.

failure_route[1] {
if (t_was_cancelled()) {
exit;
}

# uncomment the following lines if you want to block client
# redirect based on 3xx replies.
##if (t_check_status("3[0-9][0-9]")) {
##t_reply("404","Not found");
##exit;
##}

# Redirect busy calls to another destination
if (t_check_status("486")) {
xlog("Redirect busy calls\n");
xlog("before revert $ru\n");
revert_uri();
xlog("after revert $ru\n");
#If there is an AVP called fwdbusy send to it
if(avp_db_load("$ru","$avp(s:fwdbusy)")) {
$ru = $avp(s:fwdbusy);
xlog("forwarded to: $ru");
}
t_relay();
}
}


The log output was:
Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: new branch at
sip:1...@192.168.1.2 
Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: incoming
reply
Mar 19 13:34:49 danielribeiro /usr/local/sbin/opensips[26188]: onreply
invite
Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: incoming
reply
Mar 19 13:34:50 danielribeiro /usr/local/sbin/opensips[26188]: onreply
invite
Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: incoming
reply
Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: onreply
invite
Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC:
transaction answered:
timestamp=1269016498;method=INVITE;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
Mar 19 13:34:58 danielribeiro /usr/local/sbin/opensips[26188]: ACC: request
acknowledged:
timestamp=1269016498;method=ACK;from_tag=286496395;to_tag=192.168.1.2+1+106+dca82b99;call_id=
3f0187fe-c3fe-e6df-a2f3-457df8e17...@192.168.1.200;code=200;reason=OK
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch at
sip:1...@192.168.1.2 
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
reply
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
invite
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
reply
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
invite
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
reply error 486
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: ACC: call
missed:
timestamp=1269016500;method=INVITE;from_tag=c298fc07-e331-df11-91ee-002421899f1c;to_tag=192.168.1.2+1+108+b729333f;call_id=fc95fc07-e331-df11-91ee-002421899...@danielribeiro;code=486;reason=Busy
Here
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: Redirect busy
calls
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: before revert
sip:1...@192.168.1.2 
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: after revert
sip:1...@192.168.1.200 
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: forwarded to:
sip:1...@192.168.1.200 
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch at
sip:1...@192.168.1.200 
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: new branch at
sip:1...@192.168.1.2 
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
reply
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
invite
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
reply
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
invite
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: ACC: call
missed:
timestamp=1269016500;method=INVITE;from_tag=c298fc07-e331-df11-91ee-002421899f1c;to_tag=192.168.1.2+1+108+b729333f;call_id=fc95fc07-e331-df11-91ee-002421899...@xxx;code=482;reason=Loop
Detected
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: incoming
reply
Mar 19 13:35:00 danielribeiro /usr/local/sbin/opensips[26188]: onreply
invite


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

Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

[Christian Vo]

Thx Alex,
Confirming that these are my settings:

// each server is a box

$box_id=0;

// mi host:port pair || fifo_file
// $boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
$boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";

// monit host:port
$boxes[$box_id]['monit']['conn']="127.0.0.1:2812";
$boxes[$box_id]['monit']['user']="admin";
$boxes[$box_id]['monit']['pass']="monit";
$boxes[$box_id]['monit']['has_ssl']=0;

// description (appears in mi , monit )
$boxes[$box_id]['desc']="SIP server";

At this point,   Monit seems to be working, but Statistics Monitor complains

"Cannot connect to OpenSIPS Server via Management Interface (127.0.0.1/8080)


"


From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Alex Ionescu
Sent: Friday, March 19, 2010 1:42 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

Hi Christian,

Your boxes config must look like this :

$box_id=0;
// mi host:port pair || fifo_file
//$boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
//i guess you are using fifo, not xmlrpc so :
$boxes[$box_id]['mi']['conn']="/tmp/opensips_proxy_fifo";

// monit host:port => this is for monit to work ok
$boxes[$box_id]['monit']['conn']="127.0.0.1:2812";
//you must take the username and password from the monit config file (monitrc).
$boxes[$box_id]['monit']['user']="username";
$boxes[$box_id]['monit']['pass']="password";
// if you want to enable ssl
$boxes[$box_id]['monit']['has_ssl']=1;

Please re-check your config and let me know if it works now.

Regards,
Alex

On 3/19/2010 01:42, Christian Vo wrote:
New problem:

So under opensips-cp/config/boxes.global.inc.php
I changed the following:

$boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
(previously was $boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";"

This seemed to resolve my issue with System--> Monit

However,
 System --> Statistics Monitor , System--> SIP Trace  ,   System --> MI 
Commands, and System --> Dispatcher  all  complain with the following on-screen 
message

"Cannot connect to OpenSIPS Server via Management Interface (127.0.0.1/8080)"

So I changed it back to
$boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";

But then


I notice tools/monit/local.inc.php still doesn't contain any code??

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Christian Vo
Sent: Thursday, March 18, 2010 10:21 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

Thx for the notice, I've just downloaded and re-installed the lastest 4.0 
tarball  (moved the old dir to backup, and replaced it with the new, 
re-adjusting config parameters along the way...)

Not sure if I missed something, but I'm getting this error on-screen now:

Under the System--> Monit tab
I see  "Primary Sip Server"  192.168.0.1:2812

Followed by "I can't Connect"


Something is wrong here, since I adjusted config/boxes.global.inc.php so that 
my only entry (Primary SIP Server) would be using 127.0.0.1:2812 for monit
And I don't know where else I'd find any entry for 192.168.0.1 related to this..

This part was working for me back when I had the previous 4.0 tarball...  odd

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Alex Ionescu
Sent: Thursday, March 18, 2010 4:46 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

Hi,

Actually there were a few issues that were found and solved the last few days. 
I hope you won't have anymore problems if you download the new 4.0 tarball.

So, give it a try and let me know.

Regards,
Alex

On 3/18/2010 13:35, ha do wrote:
HI Alex

did you find new issue on opensips cp

Thank you
Ha`

--- On Sat, 3/13/10, Alex Ionescu  
wrote:

From: Alex Ionescu 
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0
To: "OpenSIPS users mailling list" 

Date: Saturday, March 13, 2010, 9:21 AM
Hi,

I will investigate the problem and will let you know if I find any issue.

Regards,
Alex

On 3/13/2010 06:39, Do Nguyen Ha wrote:

Hi Alex

here is mysql query:
mysql> select * from ocp_admin_privileges\G;
*** 1. row ***
 id: 58
 first_name:
  last_name:
   username: admin
   password: admin
ha1: d2abaa37a7c3db1137d385e1d8c15fd2
available_tools: all
permissions: all

so i am still getting the invalid username on opensips-cp version 4
the i remove the folder opensips-cp version 4 and replace with opensips-cp 
version 3 and now it works without problem with opensips-cp version 3

i dont change anything and step i do :
step 1. cd /var/www
step 2. delete folder opensips-cp
step 3. download the opensips-cp_3.0.tar.

Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

[Christian Vo]

Forgot to add:

I had smonitor's db.inc.php settings uncommented,
Now getting this error instead

[Fri Mar 19 09:59:50 2010] [error] [client 172.18.53.97] PHP Fatal error:  Call 
to undefined method MDB2_Error::setFetchMode() in 
/srv/www/htdocs/opensips-cp/web/tools/system/smonitor/lib/db_connect.php on 
line 39, referer: http://10.32.0.97/cp/menu.php

I'm very sure I installed pear and the related parts as per the install guide..

From: Christian Vo
Sent: Friday, March 19, 2010 9:57 AM
To: OpenSIPS users mailling list
Subject: RE: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

Thx Alex,
Confirming that these are my settings:

// each server is a box

$box_id=0;

// mi host:port pair || fifo_file
// $boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
$boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";

// monit host:port
$boxes[$box_id]['monit']['conn']="127.0.0.1:2812";
$boxes[$box_id]['monit']['user']="admin";
$boxes[$box_id]['monit']['pass']="monit";
$boxes[$box_id]['monit']['has_ssl']=0;

// description (appears in mi , monit )
$boxes[$box_id]['desc']="SIP server";

At this point,   Monit seems to be working, but Statistics Monitor complains

"Cannot connect to OpenSIPS Server via Management Interface (127.0.0.1/8080)


"


From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Alex Ionescu
Sent: Friday, March 19, 2010 1:42 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

Hi Christian,

Your boxes config must look like this :

$box_id=0;
// mi host:port pair || fifo_file
//$boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
//i guess you are using fifo, not xmlrpc so :
$boxes[$box_id]['mi']['conn']="/tmp/opensips_proxy_fifo";

// monit host:port => this is for monit to work ok
$boxes[$box_id]['monit']['conn']="127.0.0.1:2812";
//you must take the username and password from the monit config file (monitrc).
$boxes[$box_id]['monit']['user']="username";
$boxes[$box_id]['monit']['pass']="password";
// if you want to enable ssl
$boxes[$box_id]['monit']['has_ssl']=1;

Please re-check your config and let me know if it works now.

Regards,
Alex

On 3/19/2010 01:42, Christian Vo wrote:
New problem:

So under opensips-cp/config/boxes.global.inc.php
I changed the following:

$boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
(previously was $boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";"

This seemed to resolve my issue with System--> Monit

However,
 System --> Statistics Monitor , System--> SIP Trace  ,   System --> MI 
Commands, and System --> Dispatcher  all  complain with the following on-screen 
message

"Cannot connect to OpenSIPS Server via Management Interface (127.0.0.1/8080)"

So I changed it back to
$boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";

But then


I notice tools/monit/local.inc.php still doesn't contain any code??

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Christian Vo
Sent: Thursday, March 18, 2010 10:21 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

Thx for the notice, I've just downloaded and re-installed the lastest 4.0 
tarball  (moved the old dir to backup, and replaced it with the new, 
re-adjusting config parameters along the way...)

Not sure if I missed something, but I'm getting this error on-screen now:

Under the System--> Monit tab
I see  "Primary Sip Server"  192.168.0.1:2812

Followed by "I can't Connect"


Something is wrong here, since I adjusted config/boxes.global.inc.php so that 
my only entry (Primary SIP Server) would be using 127.0.0.1:2812 for monit
And I don't know where else I'd find any entry for 192.168.0.1 related to this..

This part was working for me back when I had the previous 4.0 tarball...  odd

From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Alex Ionescu
Sent: Thursday, March 18, 2010 4:46 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

Hi,

Actually there were a few issues that were found and solved the last few days. 
I hope you won't have anymore problems if you download the new 4.0 tarball.

So, give it a try and let me know.

Regards,
Alex

On 3/18/2010 13:35, ha do wrote:
HI Alex

did you find new issue on opensips cp

Thank you
Ha`

--- On Sat, 3/13/10, Alex Ionescu  
wrote:

From: Alex Ionescu 
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0
To: "OpenSIPS users mailling list" 

Date: Saturday, March 13, 2010, 9:21 AM
Hi,

I will investigate the problem and will let you know if I find any issue.

Regards,
Alex

On 3/13/2010 06:39, Do Nguyen Ha wrote:

Hi Alex

here is mysql query:
mysql> select * from ocp_admin_privileges\G;

Re: [OpenSIPS-Users] T.38 detection/redirect in OpenSIPS

[TCB]

@ All,

This has very exciting possibilities for me. I'm definitely going to look at
the
b2b module and test this out. I will share my findings.

regards

On Thu, Mar 18, 2010 at 10:32 AM, Bogdan-Andrei Iancu <
bog...@voice-system.ro> wrote:

> Hi Jeff,
>
> as opensips will act as b2b, your call will be actually split in 2 calls
> (from SIP point of view) - a call C1 from GW to opensips and another one
> C2 from opensips to UAC. So at re-INVITE time, opensips b2b will hung up
> C2 and replace it with a C3 to a new destination, bridging it with C1
>
> Regards,
> Bogdan
>
> Jeff Kronlage wrote:
> > I'm confused on this as well - wouldn't you be effectively placing two
> > calls (one via a non-T38 gateway, one via a T38 gateway) to the same
> > destination?  Figuring that most T38 is going to terminate to a single
> > analog device, I would think that were this possible at a SIP level, the
> > device would already be "busy" before the second call came in as fax
> > machines don't typically drop the line very rapidly?
> >
> > Jeff
> >
> > -Original Message-
> > From: users-boun...@lists.opensips.org
> > [mailto:users-boun...@lists.opensips.org] On Behalf Of Bogdan-Andrei
> > Iancu
> > Sent: Wednesday, March 17, 2010 11:23 AM
> > To: OpenSIPS users mailling list
> > Subject: Re: [OpenSIPS-Users] T.38 detection/redirect in OpenSIPS
> >
> > right, that is exactly what the b2b is up to do - to be able (at
> > signalling level) to manipulate the call legs
> >
> > Regards,
> > Bogdan
> >
> > Brett Nemeroff wrote:
> >
> >> Bogdan,
> >> But at this point, you are now playing with a dialg that is already
> >> connected to an endpoint. You'd need to drop the first call to
> >> establish a new call with the reinvite. Right?
> >> -Brett
> >>
> >> On Mar 17, 2010, at 11:50 AM, Bogdan-Andrei Iancu
> >>
> >  >
> >>  > wrote:
> >>
> >>
> >>
> >>> Hi Brett,
> >>>
> >>> Brett Nemeroff wrote:
> >>>
> >>>
>  I don't think there is any way to do this without an RTP capable
>  device in the mix.
> 
> 
> >>> you do not need to look into RTP as the FAX is advertised in the
> >>> re-INVITE (in SDP) - so you can detect it from opensips script by
> >>> inspecting the SDP of reINVITES
> >>>
> >>>
>  What you may be able to do is have asterisk detect that it's a fax,
>  then reject it if it is.. I don't know if you can do all that
> 
> > without
> >
>  answering the call.
> 
> 
> >>> no, you cannnot, as first the call is established (from sip point of
> >>> view) as a simple audio call and after that re-negotiated (via
> >>> re-INVITE) for FAX
> >>>
> >>>
>  Then you can forward it back to the proxy if it is a fax with maybe
> 
> > a
> >
>  prefix.
> 
>  A lot of assumptions in there. Would like to hear if you find
>  something that works. Not sure if you can SIP Spiral yet in asterisk
>  anyway. ;)
> 
> 
> >>> I do not see the need of Asterisk - maybe with some changes, the b2b
> >>> module will be able to handle this - see my prev email.
> >>>
> >>> Regards,
> >>> Bogdan
> >>>
> >>>
> >>>
>  -Brett
> 
> 
>  On Wed, Mar 17, 2010 at 10:51 AM, David J.   > wrote:
> 
> Matt,
> 
> I am for sure probably wrong, but I think you would need
>  Asterisk or
> Variant to Determine that it is a Fax Call,
> I dont think UAC's send T38 information without negotiating with
>  the
> other side who request that it is capable, then it brings you to
> Jeff's
> answer.
> 
> See above.
> 
> 
> Matthew S. Crocker wrote:
> 
> 
> > Can OpenSIPS make routing decisions based on the SDP information
> >
> >
> in an INVITE?
> 
> 
> > Lets say I have the following config
> >
> > PSTN -> t.38 Gateway -> OpenSIPS ->  UserAgent
> >
> > I have a TN from the PSTN routed to the UserAgent,  I'd like to
> >
> >
> provide a service so the user can use the TN for both voice &
>  faxing.
> 
> 
> > Voice call goes through normally (g.711 g.729 codec)
> >
> > Fax call starts off as a normal voice call (INVITE, 180, 183,
> >
> >
> 200).  Once the call is answered the originating end (PSTN)
> 
> > starts
> >
> sending fax tones. The Gateway hears the fax tones and attempts
> 
> > to
> >
> RE-INVITE with T.38 in the SDP.  I'd like OpenSIPS to see the
> 
> > T.38
> >
> capability in the SDP and redirect the call to a fax->e-mail
> gateway.  So,  the 2nd INVITE comes in, OpenSIPS sends the INVITE
> to the fax gateway and a BYE to the user.  The fax gateway does a
> 200 and negotiates T.38 with the PSTN gateway.
> 
> 
> > I know I can route the call through Asterisk and have it do a
> >
> >
> quiet answer and listen for the modem sounds.  I'd like to avoid
> >>

Re: [OpenSIPS-Users] Error message on opensips-cp 4.0

[Flavio Goncalves]

Hi Alex

user: flavio
domain: opensips.org
alias: 9
email: fla...@opensips.org.

I'm also able to insert aliases without errors.
I've installed from the tarball, not the svn,  I will try the svn version?

Thanks,

Flavio E. Goncalves


2010/3/19 Alex Ionescu :
> Hi Flavio,
>
> Can you give me some details about the user you are trying to insert ?
> Any special characters involved ?
> I will continue digging ... maybe I find something relevant regarding
> your problem.
>
> Regards,
> Alex
>
> On 3/19/2010 12:12, Flavio Goncalves wrote:
>> Hi Alex,
>>
>> Yes, I have installed php-pear and MDB2 drivers. I've checked twice,
>> the dependencies, the configuration of php.ini and database connection
>> parameters. I'm using debian 5.0.1 and  mysql 5.0.51-24. Seems to be
>> something in the prepared statements. Database connections are ok,
>> because I have created domains without any problem.
>>
>> Best regards,
>>
>> Flavio E. Goncalves
>>
>> 2010/3/19 Alex Ionescu:
>>
>>> Hi Flavio,
>>>
>>> I've checked again but on our test platform appears to work fine and
>>> this is the first time somebody reports a bug related to User
>>> Managemet/Add New.
>>>
>>> Can you please check that you have installed php-pear and MDB2 and
>>> MDB2_Driver_mysql ?
>>> Let me know if this solved your problem.
>>>
>>> Regards,
>>> Alex
>>>
>>> On 3/19/2010 00:39, Flavio Goncalves wrote:
>>>
 Fatal error: Call to undefined method MDB2_Error::execute()

>>>
>>> --
>>> Alex Ionescu
>>> www.voice-system.ro
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Alex Ionescu
> www.voice-system.ro
>
>
> ___
> 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] Error message on opensips-cp 4.0

[Alex Ionescu]

Hi Flavio,

Can you give me some details about the user you are trying to insert ? 
Any special characters involved ?
I will continue digging ... maybe I find something relevant regarding 
your problem.

Regards,
Alex

On 3/19/2010 12:12, Flavio Goncalves wrote:
> Hi Alex,
>
> Yes, I have installed php-pear and MDB2 drivers. I've checked twice,
> the dependencies, the configuration of php.ini and database connection
> parameters. I'm using debian 5.0.1 and  mysql 5.0.51-24. Seems to be
> something in the prepared statements. Database connections are ok,
> because I have created domains without any problem.
>
> Best regards,
>
> Flavio E. Goncalves
>
> 2010/3/19 Alex Ionescu:
>
>> Hi Flavio,
>>
>> I've checked again but on our test platform appears to work fine and
>> this is the first time somebody reports a bug related to User
>> Managemet/Add New.
>>
>> Can you please check that you have installed php-pear and MDB2 and
>> MDB2_Driver_mysql ?
>> Let me know if this solved your problem.
>>
>> Regards,
>> Alex
>>
>> On 3/19/2010 00:39, Flavio Goncalves wrote:
>>  
>>> Fatal error: Call to undefined method MDB2_Error::execute()
>>>
>>
>> --
>> Alex Ionescu
>> www.voice-system.ro
>>
>>
>> ___
>> 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
>
>


-- 
Alex Ionescu
www.voice-system.ro


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

Re: [OpenSIPS-Users] Error message on opensips-cp 4.0

[Flavio Goncalves]

Hi Alex,

Yes, I have installed php-pear and MDB2 drivers. I've checked twice,
the dependencies, the configuration of php.ini and database connection
parameters. I'm using debian 5.0.1 and  mysql 5.0.51-24. Seems to be
something in the prepared statements. Database connections are ok,
because I have created domains without any problem.

Best regards,

Flavio E. Goncalves

2010/3/19 Alex Ionescu :
> Hi Flavio,
>
> I've checked again but on our test platform appears to work fine and
> this is the first time somebody reports a bug related to User
> Managemet/Add New.
>
> Can you please check that you have installed php-pear and MDB2 and
> MDB2_Driver_mysql ?
> Let me know if this solved your problem.
>
> Regards,
> Alex
>
> On 3/19/2010 00:39, Flavio Goncalves wrote:
>> Fatal error: Call to undefined method MDB2_Error::execute()
>
>
> --
> Alex Ionescu
> www.voice-system.ro
>
>
> ___
> 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] Problem with OpenSIPS Control Panel 4.0

[Alex Ionescu]

Hi Christian,

Your boxes config must look like this :

$box_id=0;
// mi host:port pair || fifo_file
//$boxes[$box_id]['mi']['conn']="127.0.0.1:8080";
//i guess you are using fifo, not xmlrpc so :
$boxes[$box_id]['mi']['conn']="/tmp/opensips_proxy_fifo";

// monit host:port => this is for monit to work ok
$boxes[$box_id]['monit']['conn']="127.0.0.1:2812";
//you must take the username and password from the monit config file 
(monitrc).

$boxes[$box_id]['monit']['user']="username";
$boxes[$box_id]['monit']['pass']="password";
// if you want to enable ssl
$boxes[$box_id]['monit']['has_ssl']=1;

Please re-check your config and let me know if it works now.

Regards,
Alex

On 3/19/2010 01:42, Christian Vo wrote:


New problem:

So under opensips-cp/config/boxes.global.inc.php

I changed the following:

$boxes[$box_id]['mi']['conn']="127.0.0.1:8080";

(previously was $boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";"

This seemed to resolve my issue with Systemà Monit

However,

 System à Statistics Monitor , Systemà SIP Trace  ,   System à MI 
Commands, and System à Dispatcher  all  complain with the following 
on-screen message


"Cannot connect to OpenSIPS Server via Management Interface 
(127.0.0.1/8080)"


So I changed it back to

$boxes[$box_id]['mi']['conn']="/tmp/opensips_fifo";

But then

I notice tools/monit/local.inc.php still doesn't contain any code??

*From:* users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] *On Behalf Of *Christian Vo

*Sent:* Thursday, March 18, 2010 10:21 AM
*To:* OpenSIPS users mailling list
*Subject:* Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

Thx for the notice, I've just downloaded and re-installed the lastest 
4.0 tarball  (moved the old dir to backup, and replaced it with 
the new, re-adjusting config parameters along the way...)


Not sure if I missed something, but I'm getting this error on-screen now:

Under the Systemà Monit tab

I see  "Primary Sip Server"  192.168.0.1:2812

Followed by "I can't Connect"

Something is wrong here, since I adjusted config/boxes.global.inc.php 
so that my only entry (Primary SIP Server) would be using 
127.0.0.1:2812 for monit


And I don't know where else I'd find any entry for 192.168.0.1 related 
to this..


This part was working for me back when I had the previous 4.0 
tarball...  odd


*From:* users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] *On Behalf Of *Alex Ionescu

*Sent:* Thursday, March 18, 2010 4:46 AM
*To:* OpenSIPS users mailling list
*Subject:* Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0

Hi,

Actually there were a few issues that were found and solved the last 
few days. I hope you won't have anymore problems if you download the 
new 4.0 tarball.


So, give it a try and let me know.

Regards,
Alex

On 3/18/2010 13:35, ha do wrote:

HI Alex

did you find new issue on opensips cp

Thank you

Ha`

--- On *Sat, 3/13/10, Alex Ionescu / 
/* wrote:



From: Alex Ionescu  
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0
To: "OpenSIPS users mailling list"  


Date: Saturday, March 13, 2010, 9:21 AM

Hi,

I will investigate the problem and will let you know if I find any issue.

Regards,
Alex

On 3/13/2010 06:39, Do Nguyen Ha wrote:


Hi Alex

here is mysql query:
mysql> select * from ocp_admin_privileges\G;
*** 1. row ***
 id: 58
 first_name:
  last_name:
   username: admin
   password: admin
ha1: d2abaa37a7c3db1137d385e1d8c15fd2
available_tools: all
permissions: all

so i am still getting the invalid username on opensips-cp version 4
the i remove the folder opensips-cp version 4 and replace with 
opensips-cp version 3 and now it works without problem with 
opensips-cp version 3


i dont change anything and step i do :
step 1. cd /var/www
step 2. delete folder opensips-cp
step 3. download the opensips-cp_3.0.tar.gz
step 4. untar the file opensips-cp_3.0
step 5. chown www-data:www-data opensips-cp -R

Thank you for your help
Ha

--- On *Fri, 3/12/10, Alex Ionescu / 
/* wrote:



From: Alex Ionescu  
Subject: Re: [OpenSIPS-Users] Problem with OpenSIPS Control Panel 4.0
To: "OpenSIPS users mailling list"  


Date: Friday, March 12, 2010, 9:02 AM

Sorry,

My mistake ... the MD5 should be applied on the value not on the field 
name ... So, it is :


INSERT INTO ocp_admin_privileges 
(username,password,ha1,available_tools,permissions) values 
('admin','admin',md5('admin:admin'),'all','all');


On 3/12/2010 13:06, Alex Ionescu wrote:

Hi,

The problem seems to be your "step 11" :

  step 11. INSERT INTO ocp_admin_privileges 
(username,password,ha1,available_tools,permissions) values 
('admin','admin','admin:admin','all','all');


You must encode the *ha1* field. So, I believe that the correct query 
would be :


INSERT INTO ocp_admin_privileges

Re: [OpenSIPS-Users] Error message on opensips-cp 4.0

[Alex Ionescu]

Hi Flavio,

I've checked again but on our test platform appears to work fine and 
this is the first time somebody reports a bug related to User 
Managemet/Add New.

Can you please check that you have installed php-pear and MDB2 and 
MDB2_Driver_mysql ?
Let me know if this solved your problem.

Regards,
Alex

On 3/19/2010 00:39, Flavio Goncalves wrote:
> Fatal error: Call to undefined method MDB2_Error::execute()


-- 
Alex Ionescu
www.voice-system.ro


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

Re: [OpenSIPS-Users] Check Live Peers on OpenSIPS

[Ahmed Munir]

Hi Bogdan,

Thanks for your suggestion, few things I want to ask from you;

1- Can I use rewritehostport(); function instead of $rd='11.22.33.44' and
append it to t_relay()? Like;

setflag(2);
rewritehostport("203.215.179.34:5060");
t_relay();
route(1);
exit;

2- When using check_source_address() function of permissions module, I'm
facing weird problem. On machine A I've installed OpenSIPS ver 1.6.1 svn
one, I used this function to permitted certain source IPs as I listed in
address table. On machine B (currently working on it using Radius) I've
installed same version of OpenSIPS as on machine A, when I call its
check_source_address() function in INVITE section, it is working as it
worked on machine A. Machine A settings are listed below;


if(is_method("INVITE") && check_source_address("0"))
{
   log(" CHECK SOURCE ADDRESS
##");
   route(1);
   setflag(1);
}


Machine B description I'm mentioning below;

2-1- If user registered him/her self on SIP phone their source IP not going
to be checked, and make calls to each other.
2-2- If user A is on GW calls user B who is located and Registered on
 OpenSIPS, user A GW's source IP must be checked by OpenSIPs, if the IP
exists on address table, call is permitted if not deny the call.

Problems;

When I user A and user B registered on OpenSIPs (using Radius) they can call
each other, but if a user A calling from GW to user B who is registered on
OpenSIPs, calls is made even the address is not listed on address table. And
also in logs I see that that permissions module shows that it doesn't find
any IP enlisted in its hash table, but still permitting it. The
configuration of machine B is listed below;

# main request routing logic

route{

if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
}

if (has_totag()) {
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accounting ...
setflag(3); # ... even if the transaction
fails
} else if (is_method("INVITE")) {
record_route();
}
route(1);
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful ACK;
must be an ACK after
# a 487 or e.g. 404 from upstream
server
t_relay();
exit;
} else {
# ACK without matching transaction
->
# ignore and discard
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}

#initial requests

# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}

t_check_trans();

 # preloaded route checking
if (loose_route()) {
xlog("L_ERR",
"Attempt to route with preloaded Route's
[$fu/$tu/$ru/$ci]");
if (!is_method("ACK"))
sl_send_reply("403","Preload Route denied");
exit;
}

# record routing
if (!is_method("REGISTER|MESSAGE"))
record_route();


# account only INVITEs
if (is_method("INVITE") && check_source_address("0")){
log(" INVITE CASE 1
");
setflag(1); # do accounting
}
if (!uri==myself)
## replace with following line if multi-domain support is used
##if (!is_uri_host_local())
{
append_hf("P-hint: outbound\r\n");
# if you have some interdomain connections via TLS
##if($rd=="tls_domain1.net") {
##  t_relay("tls:domain1.net");
##  exit;
##} else if($rd=="tls_domain2.net") {
##  t_relay("tls:domain2.net");
##  exit;
##}
route(1);
}

# requests for my domain

## uncomment this if you want to enable presence server
##   and comment the next 'if' block
##   NOTE: uncomment also the definition of route[2] from  below
##if( is_method("PUBLISH|SUBSCRIBE"))
##  route(2);

if (is_method("PUBLISH"))
{
sl_send_reply("503", "Service Unavailable");
exit