Re: [OpenSIPS-Users] [OpenSIPS-Devel] [NEW] Dialog data persistence across reboot

[Bogdan-Andrei Iancu]

Hi Thomas,

I will try to reproduce this in the next days.

Thanks and regards,
Bogdan

Thomas Gelf wrote:
> Hi Bogdan,
>
> I have to correct myself - it's true that it isn't crashing any more,
> but it seems that it doesn't it's job, it doesn't store anything to
> DB.
>
> To reproduce this, please try:
>
> if(is_method("INVITE") && ! has_totag())
> {
> create_dialog();
> set_dlg_profile("test");
> }
>
> if(loose_route() && is_method("INVITE"))
> {
> if (is_in_profile("test")) {
> xlog("L_INFO", "Dialog has TEST profile");
> } else {
> xlog("L_INFO", "Dialog does NOT have TEST profile");
> }
> }
>
> Place a call, restart OpenSIPS, put call on hold (or do whatever
> you'd like to do to re-issue an INVITE-request - you'll see that
> it's saying that the profile got lost.
>
> Best regards,
> Thomas Gelf
>
>
> Bogdan-Andrei Iancu wrote:
>   
>> Hi Thomas,
>>
>> Thanks for the report - the fix is on SVN. Let me know if solved the 
>> problem.
>> 
>
>
> ___
> Devel mailing list
> de...@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>   


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

Re: [OpenSIPS-Users] pua_xmpp sip-xmpp gateway setup help

[mani sivaraman]

I tried jabberd2 instead of ejabbered. I'm not able to make opensips connect
to jabberd2 on component port 5347. I get handshake error when trying to
connect. I configured the secret correctly in the xmpp param and jabbered2
c2s.xml

Coudlu any one please help.

Jun 19 18:15:17 [23297] DBG:xmpp:net_connect: connecting to
172.16.0.141:5347...
Jun 19 18:15:17 [23297] DBG:xmpp:net_connect: connected to 172.16.0.141:5347
...
Jun 19 18:15:17 [23297] DBG:xmpp:net_printf: net_printf: []
Jun 19 18:15:17 [23297] DBG:xmpp:xmpp_component_child_process: server read
[]
Jun 19 18:15:17 [23297] DBG:xmpp:stream_node_callback: stream callback: 0:
stream:stream
Jun 19 18:15:17 [23297] DBG:xmpp:xode_send: xode_send
[ac60984ee8d1f850c98bb63ab00f0b82d9eced0e]
Jun 19 18:15:17 [23297] DBG:xmpp:xmpp_component_child_process: server read
[DIGEST-MD5]
Jun 19 18:15:17 [23297] DBG:xmpp:stream_node_callback: stream callback: 1:
stream:features
Jun 19 18:15:17 [23297] DBG:xmpp:xmpp_component_child_process: server read
[hash didn't match, auth
failed]



On Fri, Jun 19, 2009 at 3:44 PM, mani sivaraman wrote:

> HI Anca
> Thanks for your reply. Here is the setup I'm trying to establish
> (attached). All I'm trying to do is to make the SIMPLE Client (which is
> connected to opensips) talk to the Spark Client (which is connected to
> OPenfire xmpp server). Ejabbered is just used for intermediate translation.
> Right now if I disable the port 5347 on ejabbered , the C2S connection
> between opensips and ejabbered are broken and I can make a xmpp client
> connected to Ejabbered talk to the Spark Client connected to openfire.
>
> Every thing becomes higely unstable if I enable the C2S ( 5347 port) of
> ejabbered and if opensips connects to ejabbered. This makes the ejabbered go
> down every 2 min and all clients connected to ejabbered lose connection and
> status and no message is working. The openips c2s connection to ejabbered
> make the system unsable. Not sure why ?
>
> Any pointer ?
>
>
> On Fri, Jun 19, 2009 at 3:57 AM, Anca Vamanu  wrote:
>
>> Hi Mani,
>>
>> After googleing up your error returned by ejabber  I think that the
>> problem is that the domain of the xmpp buddy is not the same as the domain
>> you configured to ejabber. I see in your post that you say that the xmpp
>> server domain in xmpp.smsi.com but in the message the to uri has domain
>> dsdev-xmpp.smsi.com.
>>
>> regards,
>> Anca
>>
>> mani sivaraman wrote:
>>
>>> I see the following XMPP message communication debug from opensips server
>>> console. The opensips gets a 400 error for sending the xmpp message to
>>> openfire.
>>>
>>>
>>> Jun 18 14:28:48 [26322] DBG:xmpp:xmpp_component_child_process: got pipe
>>> cmd 2
>>> Jun 18 14:28:48 [26322] DBG:xmpp:do_send_message_component:
>>> do_send_message_component 
>>> from=[sip:msivara...@sips01.smithmicro.com>> sip%3amsivara...@sips01.smithmicro.com>]
>>> to=[sip:mani_openfire*dsdev-xmpp.smsi.com @
>>> sip-xmpp.smithmicro.com ] body=[hi]
>>> Jun 18 14:28:48 [26322] DBG:xmpp:xode_send: xode_send [>> id='smsiUA_372474835-534838778' from='msivaraman*sips01.smithmicro.com <
>>> http://sips01.smithmicro.com>@xmpp-sip.smithmicro.com <
>>> http://xmpp-sip.smithmicro.com>' 
>>> to='mani_openf...@dsdev-xmpp.smsi.com>> mani_openf...@dsdev-xmpp.smsi.com>'
>>> type='chat'>hi]
>>> Jun 18 14:28:48 [26322] DBG:xmpp:xmpp_component_child_process: server
>>> read
>>> [>> from='mani_openf...@dsdev-xmpp.smsi.com>> mani_openf...@dsdev-xmpp.smsi.com>'
>>> id='smsiUA_372474835-534838778'>hi>> type='modify'>>> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>]
>>>
>>> Could any one please help.
>>>
>>>
>>> On Thu, Jun 18, 2009 at 2:43 PM, mani sivaraman 
>>> >> mani.opens...@gmail.com>> wrote:
>>>
>>>I have the full detailed debug console out of opensips, while
>>>trying to add an xmpp buddy to my sip client connected to
>>>opensips. Seems like I get the NOTIFY for the new xmpp buddy
>>>added, but blank xml body. The message is not reaching the
>>>openfire xmpp clinet.
>>>
>>>Could any one look at the output log and tell me what is missing ?
>>>Thanks you very much
>>>
>>>
>>>
>>>On Thu, Jun 18, 2009 at 10:56 AM, mani sivaraman
>>>mailto:mani.opens...@gmail.com>> wrote:
>>>
>>>I'm new to opensips. I'm trying to setup sip-xmpp gateway
>>>using the "component" mode with a local ejabbered server. I
>>>followed the opensips.cfg found in link
>>>
>>>http://www.opensips.org/Resources/PuaXmppConfig
>>>
>>>I have 3 domains defined for my opensips server.
>>>
>>>sips01.mydomain.com  - primary
>>>opensips dns/domain defined in my sql doamin table
>>>sip-xmpp.mydoamin.com  - for
>>>gateway sip domain
>>>xmpp.mydomain.com   - for xmpp
>>>server
>>>xmpp-sip.mydomain.com 

Re: [OpenSIPS-Users] Number portability

[Bogdan-Andrei Iancu]

Hi Paul,

More or less yes :) -  you need to put translate in scripting what you 
described herestart from the default config file that comes with 
opensips. If you have more precise questions, just pot them here.

Regards,
Bogdan


Paul Mancheno H. wrote:
> Hello friends
>
> I want that a call out of my softswitch go to my OpenSIPS, there run a query 
> to a database, and return to the softswitch preceded with an index which I 
> will forward the proper operator, the most important thing is that only pass 
> signaling to OpenSIPS, and only when the call is going to do is send the data 
> packets, and ultimately the data come from softswitch to softswitch.
>
> Should I make any special configuration for this to happen?
>
> A lot of thanks.
>
>
>
> ___
> 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] Double Accounting of single Call

[Bogdan-Andrei Iancu]

Hi Shehzad,

The trace do no show anything special...The only ways you can get 
multiple ACC records for a call are:
   1) if the call spirals on your proxy (check the loopback)
   2) if you do manual acc (calling functions instead of flags).

Regards,
Bogdan

Shehzad wrote:
> Hello everyone,
>
> I am facing strange issue after migrating from old openser (1.2) to Opensips
> 1.5.1.
>
> In Opensips configuration, User can register to opensips (Nated or Public)
> and call each other or PSTN numbers.
> Media is processed by Mediaproxy. Accounting is also done. 
> I done all modification for old openser.cfg to work as opensips.cfg. and
> even I can make the call as above very well.
>
> But looking at accounting I see double INVITE entries for a single call.
> I have attached the ngrep trace for a test call between local users.
> http://pastebin.com/f43607eee
>
> Is there any thing I am missing while migrating to Opensips 1.5.1?
>
> Thanks and Regards
> Shehzad
>
>
>   


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

Re: [OpenSIPS-Users] Basic dynamic routing question

[Bogdan-Andrei Iancu]

Hi James,

The logic is a bit different that the one for lcr - the do_routing() 
functions already pushes the initial destination, so no need to do the 
"use_next_gw" after it:

route {

...
if (!do_routing("1")) {
  sl_send_reply("503", "No destination available");
  exit;
}
xlog("-gw attr is $avp(s:dr_attrs)\n");

 
if (!t_relay())
{
sl_reply_error();
}

}


Regards,
Bogdan


James Wiegand wrote:
> Hi all,
>
> I am trying to get dynamic routing working and can't seem to get any
> traction on the problem
>
> when I do a do_routing() call in the request loop nothing seems to
> happen.  I am at a loss troubleshooting this problem.  How can you
> tell what possible matches there are?
>
> Routing setup I have includes the following items - OpenSIPS 1.5.1
>
> table dr_rules:
>
> ruleidgroupid prefix  timerec priorityrouteid 
> gwlist  description
> 1 1   870 20040101T00 0   0   
> 1   Default route
>
> table dr_gateways:
>
> gwid  typeaddress  strip  pri_prefix  attrs   
> description
> 1 10  XXX.XXX.XXX.XXX  0  NULLNULLProvider
>
> route {
>
> ...
> do_routing("1");
> xlog("-gw attr is $avp(s:dr_attrs)\n");
>
> if(use_next_gw())
> {
>   if (!t_relay())
>   {
> sl_reply_error();
>   }
>   exit;
>
>
> } else {
>   sl_send_reply("503", "No destination available");
>   exit;
> }
>
> }
>
> >From the log:
>
> Jun 19 17:10:55 [9270] DBG:drouting:do_routing: using dr group 1
> Jun 19 17:10:55 [9270] DBG:drouting:internal_check_rt: found rgid 1
> (rule list 0xb60d4dc8)
> Jun 19 17:10:55 [9270] DBG:drouting:do_routing: setting attr [] as for ruri
> Jun 19 17:10:55 [9270] DBG:drouting:do_routing: setting the gw [0] as
> ruri "sip:8706569...@xxx.xxx.xxx.xxx"
> -gw attr is 
>
>
> Thanks,
>
> -jim
>   


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

Re: [OpenSIPS-Users] Call-forward and multi-leg accounting

[Bogdan-Andrei Iancu]

Hi Carlo,

maybe you should consider using manual accounting by explicitly 
triggering the radius accounting from script:
http://www.opensips.org/html/docs/modules/1.5.x/acc.html#id272212

Regards,
Bogdan

Carlo Dimaggio wrote:
> Hi all,
>
> I'm trying to implement a call-forward-unconditional with radius multi- 
> leg accounting.
> The multileg acc parameter is: modparam("acc", "multi_leg_info",  
> "Calling-Station-Id=$avp(s:cwd_src);Called-Station-Id= 
> $avp(s:cwd_dst)"), while in the request route I have this test block:
>
> $avp(s:cfu)="sip:1...@sip.xxx.it";
> avp_pushto("$ruri", "$avp(s:cfu)");
> append_branch();
> $avp(s:cwd_src)="sip:1...@sip.xxx.it";
> $avp(s:cwd_dst)="sip:1...@sip.xxx.it";
>
> The test call is: 1000 -> 1002 -> redirected to 1001
>
> My aim is to have two radius accounting messages but I have only one  
> accouting message with the multi_leg_info attached. Indeed I have seen  
> in the documentation that this should be the normal behaviour when  
> radius is used.
>
> Is there any way to achive my aim (two invite, one from 1000 to 1002  
> and one from 1002 to 1001)?
>
>
> Thank you,
> Carlo Dimaggio
>
>
>
> ___
> 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] Dispatcher module round-robin trouble

[Bogdan-Andrei Iancu]

HI Josip,

Could you be more precise about the error (make some posting) and what 
is not working?

Regards,
Bogdan

Josip Djuricic wrote:
>
> I've just tried dispatcher module and I'm having oneq 
> uestionRound-robin method (algorithm nr. 4) seams not to work 
> correctly, I'm receiving a lot of errors with it, and if I use any 
> other algorithm everything works perfectly.
>
>  
>
> But I would really like to test round-robin model.
>
>  
>
> Best regards,
>
>  
>
> Josip
>
>  
>
> 
>
> ___
> 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] my problems getting dialplan to work

[Bogdan-Andrei Iancu]

Todd,

could you please update from SVN, from branch 1.5 - I remember a fix 
related to and I'm not sure if you have it or not.

Regards,
Bogdan

Bradley, Todd wrote:
> [r...@test7 ~]# opensips -V
> version: opensips 1.5.1-notls (i386/linux)
> flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM,
> SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> svnrevision: unknown
> @(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
> main.c compiled on 11:54:04 Jun 10 2009 with gcc 4.1.2
>  
>
>   
>> -Original Message-
>> From: users-boun...@lists.opensips.org 
>> [mailto:users-boun...@lists.opensips.org] On Behalf Of 
>> Bogdan-Andrei Iancu
>> Sent: Thursday, June 18, 2009 6:36 PM
>> To: Bradley, Todd
>> Cc: users@lists.opensips.org
>> Subject: Re: [OpenSIPS-Users] my problems getting dialplan to work
>>
>> Hi Todd,
>>
>> What version of opensips are you using ? Could you pass me 
>> the output of "opensips -V" ?
>>
>> Regards,
>> Bogdan
>>
>> Bradley, Todd wrote:
>> 
>>> I'm running on GNU/Linux FC7.  I know that's pretty old, but it's 
>>> updated with all the latest package updates.  I built 
>>> opensips-1.5.1-tls from source.
>>>
>>>
>>> Todd.
>>>
>>>
>>>   
>>>   
 -Original Message-
 From: users-boun...@lists.opensips.org 
 [mailto:users-boun...@lists.opensips.org] On Behalf Of 
 
>> Bogdan-Andrei 
>> 
 Iancu
 Sent: Tuesday, June 16, 2009 11:15 AM
 To: Bradley, Todd
 Cc: users@lists.opensips.org
 Subject: Re: [OpenSIPS-Users] my problems getting dialplan to work

 Todd, this sounds like twilightzone :)...what OS are you using ?

 regards,
 Bogdan

 Bradley, Todd wrote:
 
 
> This is really baffling.  I updated my DB table to look
>   
>   
 nearly exactly
 
 
> like yours and even changed my script to look almost exactly like 
> yours, and still it doesn't work.
>
> Here's the output that was logged:
>
> Jun 16 10:35:12 [27383] DBG:dialplan:dp_get_ivalue: integer
>   
>   
 value Jun
 
 
> 16 10:35:12 [27383] DBG:dialplan:dp_translate_f: dpid is 2 Jun 16
> 10:35:12 [27383] DBG:dialplan:dp_get_svalue: searching 78 Jun 16
> 10:35:12 [27383] DBG:dialplan:dp_translate_f: input is
>   
>   
 sip:06 Jun
 
 
> 16 10:35:12 [27383] DBG:dialplan:translate: regex operator
>   
>   
 testing Jun
 
 
> 16 10:35:12 [27383] DBG:dialplan:test_match: test string 
>   
>> sip:06 
>> 
> against a pattern (sip:06.+) Jun 16 10:35:12 [27383]
> DBG:dialplan:test_match: test_match:[0]
> sip:06
> Jun 16 10:35:12 [27383] DBG:dialplan:test_match: test_match:[1]
> sip:06
> Jun 16 10:35:12 [27383] DBG:dialplan:translate: found a
>   
>   
 matching rule
 
 
> 0xb615a1f0: pr 0, match_exp (sip:06.+) Jun 16 10:35:12 [27383]
> DBG:dialplan:translate: the rule's attrs are 0 Jun 16
>   
>   
 10:35:12 [27383]
 
 
> DBG:dialplan:translate: the copied attributes
> are: 0
> Jun 16 10:35:12 [27383] DBG:dialplan:test_match: test string
> sip:06 against a pattern (sip:06.+) Jun 16 10:35:12 [27383]
> DBG:dialplan:test_match: test_match:[0]
> sip:06
> Jun 16 10:35:12 [27383] DBG:dialplan:test_match: test_match:[1]
> sip:06
> Jun 16 10:35:12 [27383] DBG:dialplan:dp_translate_f: input
>   
>   
 sip:06
 
 
> with dpid 2 => output sip:06 The variable that went in was
> sip:06 The variable that came out was sip:06
>
>
> And here is the relevant part of my route script:
>
> $var(x) = "sip:06";
> dp_translate("2", "$var(x)/$var(tmp)");
> xlog("The variable that went in was $var(x)\n");
> xlog("The variable that came out was 
>   
>> $var(tmp)\n");
>> 
> And here is the data from my dialplan table:
>
> mysql> select * from dialplan;
>
>   
>   
>> ++--++--++---++--
>> 
>> ++--++--++---++-
>> 
 

 
>> ++--++--++---++--
>> 
 
 
> ---+---+
> | id | dpid | pr | match_op | match_exp  | match_len | 
>   
>> subst_exp  |
>> 
> repl_exp   | attrs |
>
> 

Re: [OpenSIPS-Users] Load balancer sending 403 when caller hangs uo

[Bogdan-Andrei Iancu]

Hi James,

So, continuing the previous emailwhat you do by playing with the 
dialog expire param is forcing (from proxy) side to terminate the 
ongoing calls after 30 secs. As said, your call was not CANCELed, but 
was established - and you force the termination of the call after 30 
secs, that is why it works now :Dbut it is not correct.

Regards,
Bogdan

James Wiegand wrote:
> Don't know if this is the right thing to try, but when I set the
> dialog timeout the session clears after a few moments.  Is 30 seconds
> too short for use on general calling patterns?  I am looking to pass
> on the order of 700 simultaneous calls.
>
> ...
> modparam("dialog", "default_timeout", 30)
> ...
>
> -jim
>
> On Fri, Jun 19, 2009 at 9:28 AM, James
> Wiegand wrote:
>   
>> Hi Bogdan,
>>
>> Here's the dialog from a test call.
>> The remote client is Eyebeam on a PC connected to Asterisk.  I made a
>> call and hung up before answering.  The call has been terminated for
>> some time.  I can do an lb_reload to clear out the hung lb session.
>>
>> opensipsctl fifo lb_list
>> Destination:: sip:XXX.XXX.XXX.6 id=1
>>Resource:: pstn max=0 load=0
>> Destination:: sip:XXX.XXX.XXX.7 id=2
>>Resource:: pstn max=0 load=0
>> Destination:: sip:XXX.XXX.XXX.8 id=3
>>Resource:: pstn max=1 load=1
>> Destination:: sip:XXX.XXX.XXX.9 id=4
>>Resource:: pstn max=0 load=0
>>
>> opensipsctl fifo dlg_list
>> dialog::  hash=3498:265315739
>>state:: 3
>>user_flags:: 0
>>timestart:: 1245419911
>>timeout:: 99843
>>callid:: 30cd5dba1a90fbe7023054f8293fc...@yyy.yyy.yyy.12
>>from_uri:: sip:8705082...@yyy.yyy.yyy.12
>>from_tag:: as14720305
>>caller_contact:: sip:8705082...@yyy.yyy.yyy.12
>>caller_cseq:: 102
>>caller_route_set::
>>caller_bind_addr:: udp:XXX.XXX.XXX.24:5060
>>to_uri:: sip:8706569...@xxx.xxx.xxx.24
>>to_tag:: as4042950a
>>callee_contact:: sip:8706569...@xxx.xxx.xxx.8
>>callee_cseq:: 102
>>callee_route_set::
>>callee_bind_addr:: udp:XXX.XXX.XXX.24:5060
>> dialog::  hash=3895:1205860066
>>state:: 3
>>user_flags:: 0
>>timestart:: 1245419947
>>timeout:: 99879
>>callid:: 768a3fbb026fec2038c9334c05e12...@yyy.yyy.yyy.12
>>from_uri:: sip:8705082...@yyy.yyy.yyy.12
>>from_tag:: as5a726731
>>caller_contact:: sip:8705082...@yyy.yyy.yyy.12
>>caller_cseq:: 102
>>caller_route_set::
>>caller_bind_addr:: udp:XXX.XXX.XXX.24:5060
>>to_uri:: sip:8706569...@xxx.xxx.xxx.24
>>to_tag:: as3ac79c83
>>callee_contact:: sip:8706569...@xxx.xxx.xxx.8
>>callee_cseq:: 102
>>callee_route_set::
>>callee_bind_addr:: udp:XXX.XXX.XXX.24:5060
>>
>>
>> TCP SIP trace, not from the same call, but with the same result:
>>
>> 09:08:37.758213 IP (tos 0x0, ttl  45, id 34347, offset 0, flags
>> [none], proto: UDP (17), length: 855) YYY.YYY.YYY.12.sip >
>> XXX.XXX.XXX.24.sip: SIP, length: 827
>>INVITE sip:8706569...@xxx.xxx.xxx.24 SIP/2.0
>>Via: SIP/2.0/UDP YYY.YYY.YYY.12:5060;branch=z9hG4bK1fe6bb8d;rport
>>From: "device" ;tag=as0fb4ac11
>>To: 
>>Contact: 
>>Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
>>CSeq: 102 INVITE
>>User-Agent: Asterisk PBX
>>Max-Forwards: 70
>>Date: Fri, 19 Jun 2009 14:00:50 GMT
>>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
>>Supported: replaces
>>Content-Type: application/sdp
>>Content-Length: 284
>>
>>v=0
>>o=root 3848 3848 IN IP4 YYY.YYY.YYY.12
>>s=session
>>c=IN IP4 YYY.YYY.YYY.12
>>t=0 0
>>m=audio 6962 RTP/AVP 0 3 8 101
>>a=rtpmap:0 PCMU/8000
>>a=rtpmap:3 GSM/8000
>>a=rtpmap:8 PCMA/8000
>>a=rtpmap:101 telephone-event/8000
>>a=fmtp:101 0-16
>>a=silenceSupp:off - - - -
>>a=ptime:20
>>a=sendrecv
>>
>> 09:08:37.759853 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF],
>> proto: UDP (17), length: 345) XXX.XXX.XXX.24.sip > YYY.YYY.YYY.12.sip:
>> SIP, length: 317
>>SIP/2.0 100 Giving a try
>>Via: SIP/2.0/UDP YYY.YYY.YYY.12:5060;branch=z9hG4bK1fe6bb8d;rport=5060
>>From: "device" ;tag=as0fb4ac11
>>To: 
>>Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
>>CSeq: 102 INVITE
>>Server: VistaVox SIP Service
>>Content-Length: 0
>>
>>
>> 09:08:40.113592 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF],
>> proto: UDP (17), length: 874) XXX.XXX.XXX.24.sip > YYY.YYY.YYY.12.sip:
>> SIP, length: 846
>>SIP/2.0 183 Session Progress
>>Via: SIP/2.0/UDP
>> YYY.YYY.YYY.12:5060;received=YYY.YYY.YYY.12;branch=z9hG4bK1fe6bb8d;rport=5060
>>Record-Route: 
>>From: "device" ;tag=as0fb4ac11
>>To: ;tag=as2661bdde
>>Call-

Re: [OpenSIPS-Users] Load balancer sending 403 when caller hangs uo

[Bogdan-Andrei Iancu]

Hi James,

I see your call is not actually cancelled - see the negative reply on 
the CANCEL and the 200 OK on INVITE - so the call does establish and 
this is the reason for showing up in the dialog and lb module.


Regards,
Bogdan

James Wiegand wrote:
> Hi Bogdan,
>
> Here's the dialog from a test call.
> The remote client is Eyebeam on a PC connected to Asterisk.  I made a
> call and hung up before answering.  The call has been terminated for
> some time.  I can do an lb_reload to clear out the hung lb session.
>
> opensipsctl fifo lb_list
> Destination:: sip:XXX.XXX.XXX.6 id=1
> Resource:: pstn max=0 load=0
> Destination:: sip:XXX.XXX.XXX.7 id=2
> Resource:: pstn max=0 load=0
> Destination:: sip:XXX.XXX.XXX.8 id=3
> Resource:: pstn max=1 load=1
> Destination:: sip:XXX.XXX.XXX.9 id=4
> Resource:: pstn max=0 load=0
>
> opensipsctl fifo dlg_list
> dialog::  hash=3498:265315739
> state:: 3
> user_flags:: 0
> timestart:: 1245419911
> timeout:: 99843
> callid:: 30cd5dba1a90fbe7023054f8293fc...@yyy.yyy.yyy.12
> from_uri:: sip:8705082...@yyy.yyy.yyy.12
> from_tag:: as14720305
> caller_contact:: sip:8705082...@yyy.yyy.yyy.12
> caller_cseq:: 102
> caller_route_set::
> caller_bind_addr:: udp:XXX.XXX.XXX.24:5060
> to_uri:: sip:8706569...@xxx.xxx.xxx.24
> to_tag:: as4042950a
> callee_contact:: sip:8706569...@xxx.xxx.xxx.8
> callee_cseq:: 102
> callee_route_set::
> callee_bind_addr:: udp:XXX.XXX.XXX.24:5060
> dialog::  hash=3895:1205860066
> state:: 3
> user_flags:: 0
> timestart:: 1245419947
> timeout:: 99879
> callid:: 768a3fbb026fec2038c9334c05e12...@yyy.yyy.yyy.12
> from_uri:: sip:8705082...@yyy.yyy.yyy.12
> from_tag:: as5a726731
> caller_contact:: sip:8705082...@yyy.yyy.yyy.12
> caller_cseq:: 102
> caller_route_set::
> caller_bind_addr:: udp:XXX.XXX.XXX.24:5060
> to_uri:: sip:8706569...@xxx.xxx.xxx.24
> to_tag:: as3ac79c83
> callee_contact:: sip:8706569...@xxx.xxx.xxx.8
> callee_cseq:: 102
> callee_route_set::
> callee_bind_addr:: udp:XXX.XXX.XXX.24:5060
>
>
> TCP SIP trace, not from the same call, but with the same result:
>
> 09:08:37.758213 IP (tos 0x0, ttl  45, id 34347, offset 0, flags
> [none], proto: UDP (17), length: 855) YYY.YYY.YYY.12.sip >
> XXX.XXX.XXX.24.sip: SIP, length: 827
> INVITE sip:8706569...@xxx.xxx.xxx.24 SIP/2.0
> Via: SIP/2.0/UDP YYY.YYY.YYY.12:5060;branch=z9hG4bK1fe6bb8d;rport
> From: "device" ;tag=as0fb4ac11
> To: 
> Contact: 
> Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX
> Max-Forwards: 70
> Date: Fri, 19 Jun 2009 14:00:50 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> Supported: replaces
> Content-Type: application/sdp
> Content-Length: 284
>
> v=0
> o=root 3848 3848 IN IP4 YYY.YYY.YYY.12
> s=session
> c=IN IP4 YYY.YYY.YYY.12
> t=0 0
> m=audio 6962 RTP/AVP 0 3 8 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
>
> 09:08:37.759853 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF],
> proto: UDP (17), length: 345) XXX.XXX.XXX.24.sip > YYY.YYY.YYY.12.sip:
> SIP, length: 317
> SIP/2.0 100 Giving a try
> Via: SIP/2.0/UDP YYY.YYY.YYY.12:5060;branch=z9hG4bK1fe6bb8d;rport=5060
> From: "device" ;tag=as0fb4ac11
> To: 
> Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
> CSeq: 102 INVITE
> Server: VistaVox SIP Service
> Content-Length: 0
>
>
> 09:08:40.113592 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF],
> proto: UDP (17), length: 874) XXX.XXX.XXX.24.sip > YYY.YYY.YYY.12.sip:
> SIP, length: 846
> SIP/2.0 183 Session Progress
> Via: SIP/2.0/UDP
> YYY.YYY.YYY.12:5060;received=YYY.YYY.YYY.12;branch=z9hG4bK1fe6bb8d;rport=5060
> Record-Route: 
> From: "device" ;tag=as0fb4ac11
> To: ;tag=as2661bdde
> Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> Supported: replaces
> Contact: 
> Content-Type: application/sdp
> Content-Length: 262
>
> v=0
> o=root 18239 18239 IN IP4 XXX.XXX.XXX.8
> s=session
> c=IN IP4 XXX.XXX.XXX.8
> t=0 0
> m=audio 16734 RTP/AVP 0 8 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
>  

[OpenSIPS-Users] Basic dynamic routing question

[James Wiegand]

Hi all,

I am trying to get dynamic routing working and can't seem to get any
traction on the problem

when I do a do_routing() call in the request loop nothing seems to
happen.  I am at a loss troubleshooting this problem.  How can you
tell what possible matches there are?

Routing setup I have includes the following items - OpenSIPS 1.5.1

table dr_rules:

ruleid  groupid prefix  timerec priorityrouteid 
gwlist  description
1   1   870 20040101T00 0   0   
1   Default route

table dr_gateways:

gwidtypeaddress  strip  pri_prefix  attrs   
description
1   10  XXX.XXX.XXX.XXX  0  NULLNULLProvider

route {

...
do_routing("1");
xlog("-gw attr is $avp(s:dr_attrs)\n");

if(use_next_gw())
{
  if (!t_relay())
  {
sl_reply_error();
  }
  exit;


} else {
  sl_send_reply("503", "No destination available");
  exit;
}

}

>From the log:

Jun 19 17:10:55 [9270] DBG:drouting:do_routing: using dr group 1
Jun 19 17:10:55 [9270] DBG:drouting:internal_check_rt: found rgid 1
(rule list 0xb60d4dc8)
Jun 19 17:10:55 [9270] DBG:drouting:do_routing: setting attr [] as for ruri
Jun 19 17:10:55 [9270] DBG:drouting:do_routing: setting the gw [0] as
ruri "sip:8706569...@xxx.xxx.xxx.xxx"
-gw attr is 


Thanks,

-jim
-- 
-- 
Jim Wiegand
---
Home:  originaljimda...@gmail.com
AIM: originaljimdandy

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

Re: [OpenSIPS-Users] Load balancer module

[Bogdan-Andrei Iancu]

Hi Josip,

Well, the message you passed is not the most relevant one. I want to see 
the value of the $du just before sending the message out :), so please 
try adding the xlog() line before t_relay().

Regarding the routing based on cps rateI see what you mean, but 
having I guess you can also have somehow to take into consideration the 
max capacity also, so kind of combination between ongoing calls and cps.

Regards,
Bogdan

Josip Djuricic wrote:
> Hi,
>
> Ofcourse, I can send you this from yesterday log:
>
> Sorry I removed IP because of the obvious reasons.
>
> Jun 18 10:57:33 b2bua-rlf /usr/local/sbin/opensips[29756]: Selected
> destination is: sip:xxx.xxx.xxx.xxx:3
>
>
> Btw. Is there a possibility to choose destination based on cps rate?
>
> Best regards,
>
> Josip
>
> -Original Message-
> From: Bogdan-Andrei Iancu [mailto:bog...@voice-system.ro] 
> Sent: Friday, June 19, 2009 9:29 AM
> To: Josip Djuricic
> Cc: 'Brett Nemeroff'; users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] Load balancer module
>
> Hi Josip,
>
> could you print the $du variable after you successfully do load_balance() ?
>
> like add :
> xlog(" new destination is %du \n");
>
> and see if the printed URI does contain the port part also ?
>
> Regards,
> Bogdan
>
> Josip Djuricic wrote:
>   
>> Hi,
>>
>> Since we are at load_balancer module I've noticed one strange behaviour on
>> trunk and 1.5.0 version also.
>>
>> I see that every request is sent to port 5060 no matter what I've put in
>> dst_uri field...i.e. if I put sip:xxx.xxx.xxx.xxx:port_number, it will
>> 
> still
>   
>> send everything to port 5060 instead of defined port_number, ofcourse
>> looping itself if opensips is on port 5060 on the same ip.
>>
>> I've tried this with the example from the web, so perhaps I am doing
>> something wrong?
>>
>> Best regards,
>>
>> Josip
>>
>>
>>
>>
>> -Original Message-
>> From: users-boun...@lists.opensips.org
>> [mailto:users-boun...@lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
>> Sent: Friday, June 19, 2009 9:12 AM
>> To: Brett Nemeroff
>> Cc: users@lists.opensips.org
>> Subject: Re: [OpenSIPS-Users] Load balancer module
>>
>> HI Brett,
>>
>> Brett Nemeroff wrote:
>>   
>> 
>>> All,
>>> What's the actual status of the load balancer module? I see in 1.5 
>>> it's alpha/NEW. Is it usable yet?
>>> 
>>>   
>> alpha means in not 100% tested (but does not mean is not stable). Also 
>> it means that devel is still on progress as I plan to add some more 
>> features on it/
>>   
>> 
>>> I don't know how conservative those labels are.
>>> 
>>>   
>> as much as possible :)
>>
>> Regards,
>> Bogdan
>>   
>> 
>>> -Brett
>>>
>>> 
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>   
>>> 
>>>   
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>   
>> 
>
>
>
>   


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

Re: [OpenSIPS-Users] SIP CLient <- TLS --> OpenSIPS <- UDP -> SIP Server

[Bogdan-Andrei Iancu]

Hi Anil,

It might be possible...To be on the safe side, I will increase the value 
also in the SVN tree.
Thank for the debugging and I really appreciate your help on 
troubleshooting this.

Best regards,
Bogdan

Anil M Pannikode wrote:
> Looks like this is a bug / timing issue in OpenSIPS.
>
> In "tls_server.c" , function 'tls_blocking_write'
>
> If I change the 
>
> #define MAX_SSL_RETRIES 32 
>
> to
>
> #define MAX_SSL_RETRIES 320 
>
> The connection succeeds and it works. I added a few log lines and it looks
> like
>
> n = poll(&pf, 1, timeout);
>
> is returning straight away without actually waiting for timeout (revents set
> to 4) and the retries count exceeds 32 and the call fails.
>
> It is almost like it did not have enough time to receive the response.
>
> I am running OpenSIPS on a VM.
>
> I don't think this is the correct way to fix this issue. I will leave it to
> experts to handle.
>
> Regards
>
> Anil
>
>
>
> -Original Message-
> From: Anil M Pannikode (hotmail) [mailto:anilpannik...@hotmail.com] 
> Sent: Friday, June 19, 2009 5:59 AM
> To: 'Bogdan-Andrei Iancu'
> Cc: 'users@lists.opensips.org'
> Subject: RE: [OpenSIPS-Users] SIP CLient <- TLS --> OpenSIPS <- UDP -> SIP
> Server
>
> We are still not able to get TLS working. The OpsnSIPS logs shows the
> following
>
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:parse_to:
> display={"Anonymous"}, ruri={sip:anonym...@sip1.mydomain.com} 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: Method : INVITE
> from 10.10.20.246 fd sip1.mydomain.com 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:maxfwd:is_maxfwd_present: value = 70  
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:tm:t_newtran:
> transaction on entrance=0x 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:parse_headers: flags= 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:parse_to_param: tag=77243246313536411E34 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:parse_to:
> end of header reached, state=29 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:parse_to:
> display={}, ruri={sip:999...@ipgateway.mydomain.com;user=phone} 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:get_hdr_field:  [86];
> uri=[sip:999...@ipgateway.mydomain.com;user=phone]  
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:get_hdr_field: to body
> [] 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:get_hdr_field: cseq : <2>  
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:get_hdr_field: content_length=401 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:get_hdr_field: found end of header 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:parse_headers: flags=78 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:tm:t_lookup_request: start searching: hash=39696, isACK=0 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:tm:matching_3261: RFC3261 transaction matching failed 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:tm:t_lookup_request: no transaction found 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:tm:run_reqin_callbacks: trans=0xb40250e8, callback type 1, id 0 entered 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:parse_headers: flags= 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:check_via_address: params 10.10.20.246, 10.10.20.246, 0 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:_shm_resize: resize(0) called 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:tm:_reply_light: reply sent out. buf=0x82a30c0: SIP/2.0 1...,
> shmem=0xb40141c8: SIP/2.0 1 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:tm:_reply_light: finished 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:mk_proxy:
> doing DNS lookup... 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:parse_headers: flags=2000 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:tcp_send:
> no open tcp connection found, opening new one 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:print_ip:
> tcpconn_new: new tcp connection to: 10.10.20.206 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:tcpconn_new: on port 5061, type 3 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:tls_tcpconn_init: entered: Creating a whole new ssl connection 
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:tls_tcpconn_init: TLS client domain AVP found = 'sip1.mydomain.com'
>
> Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
> DBG:core:tls_find_client_domain_name: virtual TLS client domain found 
> Jun 17 03:41:23 sip-proxy

[OpenSIPS-Users] FW: SIP CLient <- TLS --> OpenSIPS <- UDP -> SIP Server

[Anil M Pannikode (hotmail)]

Looks like this is a bug / timing issue in OpenSIPS.

In "tls_server.c" , function 'tls_blocking_write'

If I change the 

#define MAX_SSL_RETRIES 32 

to

#define MAX_SSL_RETRIES 320 

The connection succeeds and it works. I added a few log lines and it looks
like

n = poll(&pf, 1, timeout);

is returning straight away without actually waiting for timeout (revents set
to 4) and the retries count exceeds 32 and the call fails.

It is almost like it did not have enough time to receive the response.

I am running OpenSIPS on a VM.

I don't think this is the correct way to fix this issue. I will leave it to
experts to handle.

Regards

Anil



-Original Message-
From: Anil M Pannikode (hotmail) [mailto:anilpannik...@hotmail.com] 
Sent: Friday, June 19, 2009 5:59 AM
To: 'Bogdan-Andrei Iancu'
Cc: 'users@lists.opensips.org'
Subject: RE: [OpenSIPS-Users] SIP CLient <- TLS --> OpenSIPS <- UDP -> SIP
Server

We are still not able to get TLS working. The OpsnSIPS logs shows the
following

Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:parse_to:
display={"Anonymous"}, ruri={sip:anonym...@sip1.mydomain.com} 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: Method : INVITE
from 10.10.20.246 fd sip1.mydomain.com 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:maxfwd:is_maxfwd_present: value = 70  
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:tm:t_newtran:
transaction on entrance=0x 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:parse_headers: flags= 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:parse_to_param: tag=77243246313536411E34 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:parse_to:
end of header reached, state=29 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:parse_to:
display={}, ruri={sip:999...@ipgateway.mydomain.com;user=phone} 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:get_hdr_field:  [86];
uri=[sip:999...@ipgateway.mydomain.com;user=phone]  
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:get_hdr_field: to body
[] 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:get_hdr_field: cseq : <2>  
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:get_hdr_field: content_length=401 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:get_hdr_field: found end of header 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:parse_headers: flags=78 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:t_lookup_request: start searching: hash=39696, isACK=0 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:matching_3261: RFC3261 transaction matching failed 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:t_lookup_request: no transaction found 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:run_reqin_callbacks: trans=0xb40250e8, callback type 1, id 0 entered 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:parse_headers: flags= 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:check_via_address: params 10.10.20.246, 10.10.20.246, 0 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:_shm_resize: resize(0) called 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:_reply_light: reply sent out. buf=0x82a30c0: SIP/2.0 1...,
shmem=0xb40141c8: SIP/2.0 1 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:_reply_light: finished 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:mk_proxy:
doing DNS lookup... 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:parse_headers: flags=2000 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:tcp_send:
no open tcp connection found, opening new one 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:print_ip:
tcpconn_new: new tcp connection to: 10.10.20.206 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tcpconn_new: on port 5061, type 3 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_tcpconn_init: entered: Creating a whole new ssl connection 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_tcpconn_init: TLS client domain AVP found = 'sip1.mydomain.com'

Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_find_client_domain_name: virtual TLS client domain found 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_tcpconn_init: found name based TLS client domain
'sip1.mydomain.com' 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_tcpconn_init: Setting in CONNECT mode (client) 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:tcp_send:
sending... 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_update_fd: New fd is 8 
Jun 17 03:41:23 sip-proxy

Re: [OpenSIPS-Users] LDAP Authentication

[Bogdan-Andrei Iancu]

Gavin,

Actually the modules does use the ldap_sasl_bind() function for binding 
to LDAP, but I guess the additional params are no passed via ldap config 
file.

Regards,
Bogdan

Gavin Henry wrote:
> This is why I submitted a feature request for the ldap_sasl_bind
> function to be added. Then a sucessful bind is all that is needed by
> opensips. The problem is converting the password to plain on the
> opensips side to use it to bind with against the ldap directory. Is
> this possible?
>
> That way, we know the digest format in sip, but we don't need to care
> about the ldap hash format (most are ssha1) *and* we don't need to
> change the directory.
>
> On 19/06/2009, Bogdan-Andrei Iancu  wrote:
>   
>> Alan,
>>
>> Could you post the part of the script taking care of the REGISTRATION
>> part, just for double checking ?
>>
>> Also, for the password...does not look ok - not sure how that value is
>> computed, but please check the Digest Auth RFC to see the definition of
>> HA1 .
>>
>> Regards,
>> Bogdan
>>
>>
>>
>> Alan Rubin wrote:
>> 
>>> (reposting to fit the list size limits)
>>>
>>> Bogdan,
>>>
>>> 2) I removed the "!" from the REGISTER section.  This seems to have at
>>> least pushed me on to the next stage of actually doing an LDAP query:
>>>
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:ldap:ldap_url_search: LDAP URL parsed into session_name
>>> [sipaccounts], base [o=ntg], scope [2], filter
>>> [(&(cn=oh5)(departmentNumber=66)(ntguserstatus=Active))]
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:ldap:lds_search: [sipaccounts]: performing LDAP search: dn [o=ntg],
>>> scope [2], filter
>>> [(&(cn=oh5)(departmentNumber=66)(ntguserstatus=Active))], client_timeout
>>> [500] usecs
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:ldap:ldap_params_search: [sipaccounts]: [1] LDAP entries found
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:auth:check_nonce: comparing
>>> [4a3ae9d1b43a57f1ad95192b98ace5030eb50d1a] and
>>> [4a3ae9d1b43a57f1ad95192b98ace5030eb50d1a]
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:auth:reserve_nonce_index: second= 12, sec_monit= -1,  index= 2
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:auth:build_auth_hf: nonce index= 2
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:auth:build_auth_hf: 'Proxy-Authenticate: Digest
>>> realm="155.205.69.126",
>>> nonce="4a3ae9d2c65c88df6909b9e945bdbaaa5e495b3a"  '
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:core:parse_headers: flags=
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:core:check_via_address: params 155.205.26.124, 155.205.26.124, 0
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:core:destroy_avp_list: destroying list (nil)
>>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>>> DBG:core:receive_msg: cleaning up
>>> ...
>>>
>>> Still failing, but this time it is code 407: Proxy Authentication
>>> Required.  Getting closer?
>>>
>>> 1) Perhaps I mean "encoded" and am just using the wrong term.  An
>>> example return from our LDAP search:
>>>  userPassword: {SSHA}twmolvRuvt11fr4GVJOxIasfcGi6yci9LIEfaUQ==
>>>
>>> Regards,
>>>
>>> Alan Rubin
>>>
>>> -Original Message-
>>> From: Bogdan-Andrei Iancu [mailto:bog...@voice-system.ro]
>>> Sent: Friday, 19 June 2009 10:52 AM
>>> To: Alan Rubin
>>> Cc: users@lists.opensips.org
>>> Subject: Re: [OpenSIPS-Users] LDAP Authentication
>>>
>>> Alan,
>>>
>>> 2 points:
>>>
>>> 1) what you mean by "encrypted" ? the module supports only ha1 encoded
>>> passwords.
>>>
>>> 2) I see you deal with a REGISTER request, but in your script you
>>> changed the auth (from DB to LDAP) only for INVITES - check in the
>>> script the second auth block (for REGISTERS) and change it in the same
>>> time as we did for the INVITEs.
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Alan Rubin wrote:
>>>
>>>   
 Bogdan,

 Thanks for your help.  I reset the configuration for calculate_ha1 to

 
>>> 0
>>>
>>>   
 (it was set to 1), but I am still getting a "401 - Unauthorized"

 
>>> error.
>>>
>>>   
 The password returning from the LDAP server should be an encrypted
 string.

 # - auth_db params -
 /* uncomment the following lines if you want to enable the DB based
authentication */
 #modparam("auth_db", "calculate_ha1", yes)
 #modparam("auth_db", "password_column", "password")
 #modparam("auth_db", "db_url",
 #   "mysql://opensips:@localhost/opensips")
 #modparam("auth_db", "load_credentials", "")

 # -- auth params -
 #modparam("auth", "username_spec", "$var(username)")
 #modparam("auth", "password_spec", "$avp(s:passwo

Re: [OpenSIPS-Users] limit number of outbound calls using DIALOG

[Bogdan-Andrei Iancu]

And there is also a Tutorial on this:
http://www.opensips.org/Resources/DocsTutConcurrentCalls

Regards,
Bogdan

Alex Balashov wrote:
> Use a dialog profile.  Use $fu as the key ("value").  Check if profile 
> size is > 1, refuse the call.
>
> That's what they're there for.
>
> Jayesh Nambiar wrote:
>
>   
>> Hi,
>> I am looking at an option to limit more than one call per user even if 
>> they are registered from multiple locations.
>> Basically if User A calls from location A and if the call is active, 
>> User A registered from location B should not be allowed to make a call. 
>> What I did was:
>>
>> 1) Create a dialog after every initial INVITE initiated by users
>> 2) Before creating the dialog, query the dialog table to check if $fu 
>> has an entry in the dialog table using avp_db_query.
>> 3) If yes, means user A is already on a call so send a 403, Forbidden.
>> 4) Else, create the dialog and process call.
>>
>> Although this works, i just wonder if doing avp_db_query everytime to 
>> check if the caller has a call active is an efficient way of doing it??
>> Is it possible to store these dialog parameters in localcache using 
>> memcache module or access the dialog parameters from memory and compare 
>> it with the INVITE messages !!!
>>
>> Just trying to find a more efficient way of achieving this.
>>
>> Thanks for any inputs you might have !!
>>
>> --- Jay
>>
>>
>> 
>>
>> ___
>> 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] my problems getting dialplan to work

[Bradley, Todd]

[r...@test7 ~]# opensips -V
version: opensips 1.5.1-notls (i386/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM,
SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 11:54:04 Jun 10 2009 with gcc 4.1.2
 

> -Original Message-
> From: users-boun...@lists.opensips.org 
> [mailto:users-boun...@lists.opensips.org] On Behalf Of 
> Bogdan-Andrei Iancu
> Sent: Thursday, June 18, 2009 6:36 PM
> To: Bradley, Todd
> Cc: users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] my problems getting dialplan to work
> 
> Hi Todd,
> 
> What version of opensips are you using ? Could you pass me 
> the output of "opensips -V" ?
> 
> Regards,
> Bogdan
> 
> Bradley, Todd wrote:
> > I'm running on GNU/Linux FC7.  I know that's pretty old, but it's 
> > updated with all the latest package updates.  I built 
> > opensips-1.5.1-tls from source.
> >
> >
> > Todd.
> >
> >
> >   
> >> -Original Message-
> >> From: users-boun...@lists.opensips.org 
> >> [mailto:users-boun...@lists.opensips.org] On Behalf Of 
> Bogdan-Andrei 
> >> Iancu
> >> Sent: Tuesday, June 16, 2009 11:15 AM
> >> To: Bradley, Todd
> >> Cc: users@lists.opensips.org
> >> Subject: Re: [OpenSIPS-Users] my problems getting dialplan to work
> >>
> >> Todd, this sounds like twilightzone :)...what OS are you using ?
> >>
> >> regards,
> >> Bogdan
> >>
> >> Bradley, Todd wrote:
> >> 
> >>> This is really baffling.  I updated my DB table to look
> >>>   
> >> nearly exactly
> >> 
> >>> like yours and even changed my script to look almost exactly like 
> >>> yours, and still it doesn't work.
> >>>
> >>> Here's the output that was logged:
> >>>
> >>> Jun 16 10:35:12 [27383] DBG:dialplan:dp_get_ivalue: integer
> >>>   
> >> value Jun
> >> 
> >>> 16 10:35:12 [27383] DBG:dialplan:dp_translate_f: dpid is 2 Jun 16
> >>> 10:35:12 [27383] DBG:dialplan:dp_get_svalue: searching 78 Jun 16
> >>> 10:35:12 [27383] DBG:dialplan:dp_translate_f: input is
> >>>   
> >> sip:06 Jun
> >> 
> >>> 16 10:35:12 [27383] DBG:dialplan:translate: regex operator
> >>>   
> >> testing Jun
> >> 
> >>> 16 10:35:12 [27383] DBG:dialplan:test_match: test string 
> sip:06 
> >>> against a pattern (sip:06.+) Jun 16 10:35:12 [27383]
> >>> DBG:dialplan:test_match: test_match:[0]
> >>> sip:06
> >>> Jun 16 10:35:12 [27383] DBG:dialplan:test_match: test_match:[1]
> >>> sip:06
> >>> Jun 16 10:35:12 [27383] DBG:dialplan:translate: found a
> >>>   
> >> matching rule
> >> 
> >>> 0xb615a1f0: pr 0, match_exp (sip:06.+) Jun 16 10:35:12 [27383]
> >>> DBG:dialplan:translate: the rule's attrs are 0 Jun 16
> >>>   
> >> 10:35:12 [27383]
> >> 
> >>> DBG:dialplan:translate: the copied attributes
> >>> are: 0
> >>> Jun 16 10:35:12 [27383] DBG:dialplan:test_match: test string
> >>> sip:06 against a pattern (sip:06.+) Jun 16 10:35:12 [27383]
> >>> DBG:dialplan:test_match: test_match:[0]
> >>> sip:06
> >>> Jun 16 10:35:12 [27383] DBG:dialplan:test_match: test_match:[1]
> >>> sip:06
> >>> Jun 16 10:35:12 [27383] DBG:dialplan:dp_translate_f: input
> >>>   
> >> sip:06
> >> 
> >>> with dpid 2 => output sip:06 The variable that went in was
> >>> sip:06 The variable that came out was sip:06
> >>>
> >>>
> >>> And here is the relevant part of my route script:
> >>>
> >>> $var(x) = "sip:06";
> >>> dp_translate("2", "$var(x)/$var(tmp)");
> >>> xlog("The variable that went in was $var(x)\n");
> >>> xlog("The variable that came out was 
> $var(tmp)\n");
> >>>
> >>>
> >>> And here is the data from my dialplan table:
> >>>
> >>> mysql> select * from dialplan;
> >>>
> >>>   
> >> 
> ++--++--++---++--
> >> 
> ++--++--++---++-
> >> 
> >> 
> ++--++--++---++--
> >> 
> >>> ---+---+
> >>> | id | dpid | pr | match_op | match_exp  | match_len | 
> subst_exp  |
> >>> repl_exp   | attrs |
> >>>
> >>>   
> >> 
> ++--++--++---++--
> >> 
> ++--++--++---++-
> >> 
> >> 
> ++--++--++---++--
> >> 
> >>> ---+---+
> >>> |  7 |2 |  0 |1 | (sip:06.+) | 0 | 
> (sip:06.+) |
> >>> \...@10.47.19.24 | 0 |
> >>>
> >>>   
> >> 
> ++--++--++---++--
> >> 
> ++--++--++---++-
> >> 
> >> 
> ++--++

[OpenSIPS-Users] Double Accounting of single Call

[Shehzad]

Hello everyone,

I am facing strange issue after migrating from old openser (1.2) to Opensips
1.5.1.

In Opensips configuration, User can register to opensips (Nated or Public)
and call each other or PSTN numbers.
Media is processed by Mediaproxy. Accounting is also done. 
I done all modification for old openser.cfg to work as opensips.cfg. and
even I can make the call as above very well.

But looking at accounting I see double INVITE entries for a single call.
I have attached the ngrep trace for a test call between local users.
http://pastebin.com/f43607eee

Is there any thing I am missing while migrating to Opensips 1.5.1?

Thanks and Regards
Shehzad


-- 
View this message in context: 
http://n2.nabble.com/Double-Accounting-of-single-Call-tp3120732p3120732.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.


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

Re: [OpenSIPS-Users] Load balancer sending 403 when caller hangs uo

[James Wiegand]

Don't know if this is the right thing to try, but when I set the
dialog timeout the session clears after a few moments.  Is 30 seconds
too short for use on general calling patterns?  I am looking to pass
on the order of 700 simultaneous calls.

...
modparam("dialog", "default_timeout", 30)
...

-jim

On Fri, Jun 19, 2009 at 9:28 AM, James
Wiegand wrote:
> Hi Bogdan,
>
> Here's the dialog from a test call.
> The remote client is Eyebeam on a PC connected to Asterisk.  I made a
> call and hung up before answering.  The call has been terminated for
> some time.  I can do an lb_reload to clear out the hung lb session.
>
> opensipsctl fifo lb_list
> Destination:: sip:XXX.XXX.XXX.6 id=1
>        Resource:: pstn max=0 load=0
> Destination:: sip:XXX.XXX.XXX.7 id=2
>        Resource:: pstn max=0 load=0
> Destination:: sip:XXX.XXX.XXX.8 id=3
>        Resource:: pstn max=1 load=1
> Destination:: sip:XXX.XXX.XXX.9 id=4
>        Resource:: pstn max=0 load=0
>
> opensipsctl fifo dlg_list
> dialog::  hash=3498:265315739
>        state:: 3
>        user_flags:: 0
>        timestart:: 1245419911
>        timeout:: 99843
>        callid:: 30cd5dba1a90fbe7023054f8293fc...@yyy.yyy.yyy.12
>        from_uri:: sip:8705082...@yyy.yyy.yyy.12
>        from_tag:: as14720305
>        caller_contact:: sip:8705082...@yyy.yyy.yyy.12
>        caller_cseq:: 102
>        caller_route_set::
>        caller_bind_addr:: udp:XXX.XXX.XXX.24:5060
>        to_uri:: sip:8706569...@xxx.xxx.xxx.24
>        to_tag:: as4042950a
>        callee_contact:: sip:8706569...@xxx.xxx.xxx.8
>        callee_cseq:: 102
>        callee_route_set::
>        callee_bind_addr:: udp:XXX.XXX.XXX.24:5060
> dialog::  hash=3895:1205860066
>        state:: 3
>        user_flags:: 0
>        timestart:: 1245419947
>        timeout:: 99879
>        callid:: 768a3fbb026fec2038c9334c05e12...@yyy.yyy.yyy.12
>        from_uri:: sip:8705082...@yyy.yyy.yyy.12
>        from_tag:: as5a726731
>        caller_contact:: sip:8705082...@yyy.yyy.yyy.12
>        caller_cseq:: 102
>        caller_route_set::
>        caller_bind_addr:: udp:XXX.XXX.XXX.24:5060
>        to_uri:: sip:8706569...@xxx.xxx.xxx.24
>        to_tag:: as3ac79c83
>        callee_contact:: sip:8706569...@xxx.xxx.xxx.8
>        callee_cseq:: 102
>        callee_route_set::
>        callee_bind_addr:: udp:XXX.XXX.XXX.24:5060
>
>
> TCP SIP trace, not from the same call, but with the same result:
>
> 09:08:37.758213 IP (tos 0x0, ttl  45, id 34347, offset 0, flags
> [none], proto: UDP (17), length: 855) YYY.YYY.YYY.12.sip >
> XXX.XXX.XXX.24.sip: SIP, length: 827
>        INVITE sip:8706569...@xxx.xxx.xxx.24 SIP/2.0
>        Via: SIP/2.0/UDP YYY.YYY.YYY.12:5060;branch=z9hG4bK1fe6bb8d;rport
>        From: "device" ;tag=as0fb4ac11
>        To: 
>        Contact: 
>        Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
>        CSeq: 102 INVITE
>        User-Agent: Asterisk PBX
>        Max-Forwards: 70
>        Date: Fri, 19 Jun 2009 14:00:50 GMT
>        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
>        Supported: replaces
>        Content-Type: application/sdp
>        Content-Length: 284
>
>        v=0
>        o=root 3848 3848 IN IP4 YYY.YYY.YYY.12
>        s=session
>        c=IN IP4 YYY.YYY.YYY.12
>        t=0 0
>        m=audio 6962 RTP/AVP 0 3 8 101
>        a=rtpmap:0 PCMU/8000
>        a=rtpmap:3 GSM/8000
>        a=rtpmap:8 PCMA/8000
>        a=rtpmap:101 telephone-event/8000
>        a=fmtp:101 0-16
>        a=silenceSupp:off - - - -
>        a=ptime:20
>        a=sendrecv
>
> 09:08:37.759853 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF],
> proto: UDP (17), length: 345) XXX.XXX.XXX.24.sip > YYY.YYY.YYY.12.sip:
> SIP, length: 317
>        SIP/2.0 100 Giving a try
>        Via: SIP/2.0/UDP YYY.YYY.YYY.12:5060;branch=z9hG4bK1fe6bb8d;rport=5060
>        From: "device" ;tag=as0fb4ac11
>        To: 
>        Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
>        CSeq: 102 INVITE
>        Server: VistaVox SIP Service
>        Content-Length: 0
>
>
> 09:08:40.113592 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF],
> proto: UDP (17), length: 874) XXX.XXX.XXX.24.sip > YYY.YYY.YYY.12.sip:
> SIP, length: 846
>        SIP/2.0 183 Session Progress
>        Via: SIP/2.0/UDP
> YYY.YYY.YYY.12:5060;received=YYY.YYY.YYY.12;branch=z9hG4bK1fe6bb8d;rport=5060
>        Record-Route: 
>        From: "device" ;tag=as0fb4ac11
>        To: ;tag=as2661bdde
>        Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
>        CSeq: 102 INVITE
>        User-Agent: Asterisk PBX
>        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
>        Supported: replaces
>        Contact: 
>        Content-Type: application/sdp
>        Content-Length: 262
>
>        v=0
>        o=root 18239 18239 IN IP4 XXX.XXX.XXX.8
>        s=session
>        c=IN IP4 XXX.XXX.XXX.8
>        t=0 0
>        m=audio 16734 RTP/AVP 0 8 101
>        a=rtpmap:0 PCMU/8000
>        a=rtpmap:8 PCMA/80

Re: [OpenSIPS-Users] Load balancer sending 403 when caller hangs uo

[James Wiegand]

Hi Bogdan,

Here's the dialog from a test call.
The remote client is Eyebeam on a PC connected to Asterisk.  I made a
call and hung up before answering.  The call has been terminated for
some time.  I can do an lb_reload to clear out the hung lb session.

opensipsctl fifo lb_list
Destination:: sip:XXX.XXX.XXX.6 id=1
Resource:: pstn max=0 load=0
Destination:: sip:XXX.XXX.XXX.7 id=2
Resource:: pstn max=0 load=0
Destination:: sip:XXX.XXX.XXX.8 id=3
Resource:: pstn max=1 load=1
Destination:: sip:XXX.XXX.XXX.9 id=4
Resource:: pstn max=0 load=0

opensipsctl fifo dlg_list
dialog::  hash=3498:265315739
state:: 3
user_flags:: 0
timestart:: 1245419911
timeout:: 99843
callid:: 30cd5dba1a90fbe7023054f8293fc...@yyy.yyy.yyy.12
from_uri:: sip:8705082...@yyy.yyy.yyy.12
from_tag:: as14720305
caller_contact:: sip:8705082...@yyy.yyy.yyy.12
caller_cseq:: 102
caller_route_set::
caller_bind_addr:: udp:XXX.XXX.XXX.24:5060
to_uri:: sip:8706569...@xxx.xxx.xxx.24
to_tag:: as4042950a
callee_contact:: sip:8706569...@xxx.xxx.xxx.8
callee_cseq:: 102
callee_route_set::
callee_bind_addr:: udp:XXX.XXX.XXX.24:5060
dialog::  hash=3895:1205860066
state:: 3
user_flags:: 0
timestart:: 1245419947
timeout:: 99879
callid:: 768a3fbb026fec2038c9334c05e12...@yyy.yyy.yyy.12
from_uri:: sip:8705082...@yyy.yyy.yyy.12
from_tag:: as5a726731
caller_contact:: sip:8705082...@yyy.yyy.yyy.12
caller_cseq:: 102
caller_route_set::
caller_bind_addr:: udp:XXX.XXX.XXX.24:5060
to_uri:: sip:8706569...@xxx.xxx.xxx.24
to_tag:: as3ac79c83
callee_contact:: sip:8706569...@xxx.xxx.xxx.8
callee_cseq:: 102
callee_route_set::
callee_bind_addr:: udp:XXX.XXX.XXX.24:5060


TCP SIP trace, not from the same call, but with the same result:

09:08:37.758213 IP (tos 0x0, ttl  45, id 34347, offset 0, flags
[none], proto: UDP (17), length: 855) YYY.YYY.YYY.12.sip >
XXX.XXX.XXX.24.sip: SIP, length: 827
INVITE sip:8706569...@xxx.xxx.xxx.24 SIP/2.0
Via: SIP/2.0/UDP YYY.YYY.YYY.12:5060;branch=z9hG4bK1fe6bb8d;rport
From: "device" ;tag=as0fb4ac11
To: 
Contact: 
Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 19 Jun 2009 14:00:50 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 284

v=0
o=root 3848 3848 IN IP4 YYY.YYY.YYY.12
s=session
c=IN IP4 YYY.YYY.YYY.12
t=0 0
m=audio 6962 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

09:08:37.759853 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 345) XXX.XXX.XXX.24.sip > YYY.YYY.YYY.12.sip:
SIP, length: 317
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP YYY.YYY.YYY.12:5060;branch=z9hG4bK1fe6bb8d;rport=5060
From: "device" ;tag=as0fb4ac11
To: 
Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
CSeq: 102 INVITE
Server: VistaVox SIP Service
Content-Length: 0


09:08:40.113592 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 874) XXX.XXX.XXX.24.sip > YYY.YYY.YYY.12.sip:
SIP, length: 846
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
YYY.YYY.YYY.12:5060;received=YYY.YYY.YYY.12;branch=z9hG4bK1fe6bb8d;rport=5060
Record-Route: 
From: "device" ;tag=as0fb4ac11
To: ;tag=as2661bdde
Call-ID: 6d25870c2c9d32c90c6e4498079dc...@yyy.yyy.yyy.12
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: 
Content-Type: application/sdp
Content-Length: 262

v=0
o=root 18239 18239 IN IP4 XXX.XXX.XXX.8
s=session
c=IN IP4 XXX.XXX.XXX.8
t=0 0
m=audio 16734 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

09:08:55.476673 IP (tos 0x0, ttl  45, id 34348, offset 0, flags
[none], proto: UDP (17), length: 372) YYY.YYY.YYY.12.sip >
XXX.XXX.XXX.24.sip: SIP, length: 344
CANCEL sip:8706569...@xxx.xxx.xxx.24 SIP/2.0
Via: SIP/2.0/UDP YYY.YYY.YYY.12:5060;branch=z9hG4bK1fe6bb8d;rport
From: "device" ;tag=as0fb4ac11
To: 
Call-ID: 6d25870c2c9d

Re: [OpenSIPS-Users] Quota system problem

[Adrian Georgescu]

Your description is too vague to draw any conclusions.

What do you have in the radius table in the radacct.Price column and  
what do you have in the subscriber.quota field for a user?


Adrian

On Jun 19, 2009, at 3:31 PM, ASHWINI NAIDU wrote:


It just displays  checking the databases to block the users to quota

no quota exceeded.

though there are users whose quota is exceeded.









On Fri, Jun 19, 2009 at 6:19 PM, Adrian Georgescu projects.com> wrote:

What happens when you run it? What is displayed in the syslog?

Adrian

On Jun 19, 2009, at 11:07 AM, ASHWINI NAIDU wrote:


hi Adrian,

I am running it in cron job every minute. but the user is not  
added to quota group at all. even the quota_)usage is not getting  
populated




On Fri, Jun 19, 2009 at 2:09 PM, Adrian Georgescu projects.com> wrote:

You must run this script for anything to happen:

/var/www/CDRTool/scripts/OpenSIPS/quotaCheck.php

Visit syslog to see what happens while running it.

Adrian



On Jun 19, 2009, at 10:07 AM, ASHWINI NAIDU wrote:

hi all,

  I have installed opensips1.5,radius-2.1.4 and CDRTool-6.7.7. I am  
trying to workout quota for postpaid users. I have added the quota  
column in opensips.subscriber table. When the postpaid user makes a  
call the usage information is not inserted in quota_usage. Even if  
the quota for the month is over the user is not added to the quota  
group in opensips.grp. I am running only quotaCheck.php script in  
the cron job.


can anyone help me out with this problem or can anyone give me more  
information on quota system of cdrtool.


--
Thanking You,
Ashwini BR Naidu
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




--
Thanking You,
Ashwini BR Naidu





--
Thanking You,
Ashwini BR Naidu


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

Re: [OpenSIPS-Users] Mediaproxy - timeout issue if ringing for more than 60 seconds

[Thomas Gelf]

As you can see I rewrote all IPs, Call-IDs etc - I did so for obvious
reasons, wouldn't disclose too many details to the public. There are two
Mediaproxy Relays, OpensSIPS, another SIP Proxy, some Cisco Routers, a
B2BUA and two UAC's (only one of them is triggering engage_media_proxy)
involved in the shown call example. I could simplify the whole thing,
just calling from a SIP phone, leaving away the whole PSTN part - but
the result doesn't change.

What do you expect to see in the trace / what part are you interested
in? RTP coming from the UACs? RTP at the Mediaproxy-Relays? SDP? Please
note that the only difference (triggering the failure) is whether it
takes 60- or 61+ seconds 'til the call is being picked up.

Both endpoints doing the RTP are on public IPs, no NAT involved - they
are just forced to use Mediaproxy. I guess the reason must be some
timeout, probably forced by Mediaproxy.

Cheers,
Thomas

Josip Djuricic wrote:
> Could you include tcpdump?
> 
> Best regards, 
> 
> Josip
> 
> -Original Message-
> From: users-boun...@lists.opensips.org
> [mailto:users-boun...@lists.opensips.org] On Behalf Of Thomas Gelf
> Sent: Friday, June 19, 2009 3:04 PM
> To: users@lists.opensips.org
> Subject: [OpenSIPS-Users] Mediaproxy - timeout issue if ringing for more
> than 60 seconds
> 
> Hi list,
> 
> there must be a hidden timeout between the initial INVITE and the first
> provisional response with SDP - it seems to equal 60 seconds. Therefore
> you hear nothing if you pick up your call after 60 seconds. I tried to
> document a whole call, going to Voicemail after 61 seconds. While doing
> my tests I also played around with some undocumented setting, without
> success (relay_recover_interval).
> 
> Here the call trace (please note that the same call is fine if VM picks
> up the call within 60 seconds):
> 
> # Call from PSTN (0212345678) to local user (0276543210,
> # my-u...@mydomain.tld, vmbox: 12345):
> 
> 13:49:50 OpenSIPS[762]: New dialog from trusted peer - M=INVITE
> RURI=sip:0276543...@my.proxy.tld F=sip:0212345678-ofeypgxi...@public.gmane.org
> T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 
> id=some-call-id-ofeypgxi...@public.gmane.org
> 13:49:50 OpenSIPS[762]: Callee was aliased, PSTN - M=INVITE
> RURI=sip:my-u...@mydomain.tld F=sip:0212345678-ofeypgxi...@public.gmane.org
> T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 
> id=some-call-id-ofeypgxi...@public.gmane.org
> 13:49:50 OpenSIPS[762]: Setting ring timeout to 60 secs - M=INVITE
> RURI=sip:my-u...@mydomain.tld F=sip:0212345678-ofeypgxi...@public.gmane.org
> T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 
> id=some-call-id-ofeypgxi...@public.gmane.org
> 
> # Two branches are forked, however there is only one of them in my logs
> # (need to move that xlog()-statement to branch_route):
> 
> 13:49:50 OpenSIPS[762]: Local user online - M=INVITE
> RURI=sip:my-u...@10.0.0.10:1025;line=iqdxv6hz 
> F=sip:0212345678-ofeypgxi...@public.gmane.org
> T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 
> id=some-call-id-ofeypgxi...@public.gmane.org
> 13:49:50 OpenSIPS[762]: Request leaving server,
> D-URI='sip:111.2.3.5:51076' - M=INVITE
> RURI=sip:my-u...@10.0.0.10:1025;line=iqdxv6hz 
> F=sip:0212345678-ofeypgxi...@public.gmane.org
> T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 
> id=some-call-id-ofeypgxi...@public.gmane.org
> 13:49:50 media-dispatcher[1697]: debug: Issuing "update" command to
> relay at 90.1.2.3
> 
> # On one of the relay hosts the call is prepared:
> 
> 13:49:50 media-relay[690]: debug: Received new SDP offer
> 13:49:50 media-relay[690]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 54436
> 13:49:50 media-relay[690]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 54437
> 13:49:50 media-relay[690]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 54438
> 13:49:50 media-relay[690]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 54439
> 13:49:50 media-relay[690]: debug: Added new stream: (audio)
> 100.3.4.5:60846 (RTP: Unknown, RTCP: Unknown) <-> 90.1.2.3:54436 <->
> 90.1.2.3:54438 <-> Unknown (RTP: Unknown, RTCP: Unknown)
> 13:49:50 media-relay[690]: debug: created new session
> some-call...@80.2.3.5: 0212345678-ofeypgxi...@public.gmane.org 
> (69D9B578-1DC8) -->
> 0276543...@outbound.tld
> 
> # Both devices are ringing:
> 
> 13:49:50 OpenSIPS[769]: Reply - S=100 D=Trying F=sip:0212345...@80.2.3.5
> T=sip:0276543...@outbound.tld SRC=111.2.3.4:61000 
> id=some-call-id-ofeypgxi...@public.gmane.org
> 13:49:50 OpenSIPS[771]: Reply - S=180 D=Ringing
> F=sip:0212345...@80.2.3.5 
> T=sip:0276543210-XXmmhdotwGcVpVtQvJkt/w...@public.gmane.org
> SRC=111.2.3.5:51076 i...@‚\­õ8¸o*
> 13:49:50 OpenSIPS[757]: Reply - S=180 D=Ringing
> F=sip:0212345...@80.2.3.5 
> T=sip:0276543210-XXmmhdotwGcVpVtQvJkt/w...@public.gmane.org
> SRC=111.2.3.4:61000 i...@‚\­õ8¸o*
> 
> # Timeout happens, 60 secs are over, call is redirected to VM Server,
> # the two active branches are cancelled
> 
> 13:50:51 OpenS

Re: [OpenSIPS-Users] Quota system problem

[ASHWINI NAIDU]

It just displays  checking the databases to block the users to quota

no quota exceeded.

though there are users whose quota is exceeded.



On Fri, Jun 19, 2009 at 6:19 PM, Adrian Georgescu wrote:

> What happens when you run it? What is displayed in the syslog?
> Adrian
>
> On Jun 19, 2009, at 11:07 AM, ASHWINI NAIDU wrote:
>
> hi Adrian,
>
> I am running it in cron job every minute. but the user is not added to
> quota group at all. even the quota_)usage is not getting populated
>
>
>
> On Fri, Jun 19, 2009 at 2:09 PM, Adrian Georgescu wrote:
>
>> You must run this script for anything to happen:
>>
>> /var/www/CDRTool/scripts/OpenSIPS/quotaCheck.php
>>
>> Visit syslog to see what happens while running it.
>>
>> Adrian
>>
>>
>>
>> On Jun 19, 2009, at 10:07 AM, ASHWINI NAIDU wrote:
>>
>>  hi all,
>>>
>>>   I have installed opensips1.5,radius-2.1.4 and CDRTool-6.7.7. I am
>>> trying to workout quota for postpaid users. I have added the quota column in
>>> opensips.subscriber table. When the postpaid user makes a call the usage
>>> information is not inserted in quota_usage. Even if the quota for the month
>>> is over the user is not added to the quota group in opensips.grp. I am
>>> running only quotaCheck.php script in the cron job.
>>>
>>> can anyone help me out with this problem or can anyone give me more
>>> information on quota system of cdrtool.
>>>
>>> --
>>> Thanking You,
>>> Ashwini BR Naidu
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>
>
> --
> Thanking You,
> Ashwini BR Naidu
>
>
>


-- 
Thanking You,
Ashwini BR Naidu
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Mediaproxy - timeout issue if ringing for more than 60 seconds

[Josip Djuricic]

Could you include tcpdump?

Best regards, 

Josip

-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Thomas Gelf
Sent: Friday, June 19, 2009 3:04 PM
To: users@lists.opensips.org
Subject: [OpenSIPS-Users] Mediaproxy - timeout issue if ringing for more
than 60 seconds

Hi list,

there must be a hidden timeout between the initial INVITE and the first
provisional response with SDP - it seems to equal 60 seconds. Therefore
you hear nothing if you pick up your call after 60 seconds. I tried to
document a whole call, going to Voicemail after 61 seconds. While doing
my tests I also played around with some undocumented setting, without
success (relay_recover_interval).

Here the call trace (please note that the same call is fine if VM picks
up the call within 60 seconds):

# Call from PSTN (0212345678) to local user (0276543210,
# my-u...@mydomain.tld, vmbox: 12345):

13:49:50 OpenSIPS[762]: New dialog from trusted peer - M=INVITE
RURI=sip:0276543...@my.proxy.tld F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5
13:49:50 OpenSIPS[762]: Callee was aliased, PSTN - M=INVITE
RURI=sip:my-u...@mydomain.tld F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5
13:49:50 OpenSIPS[762]: Setting ring timeout to 60 secs - M=INVITE
RURI=sip:my-u...@mydomain.tld F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5

# Two branches are forked, however there is only one of them in my logs
# (need to move that xlog()-statement to branch_route):

13:49:50 OpenSIPS[762]: Local user online - M=INVITE
RURI=sip:my-u...@10.0.0.10:1025;line=iqdxv6hz F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5
13:49:50 OpenSIPS[762]: Request leaving server,
D-URI='sip:111.2.3.5:51076' - M=INVITE
RURI=sip:my-u...@10.0.0.10:1025;line=iqdxv6hz F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5
13:49:50 media-dispatcher[1697]: debug: Issuing "update" command to
relay at 90.1.2.3

# On one of the relay hosts the call is prepared:

13:49:50 media-relay[690]: debug: Received new SDP offer
13:49:50 media-relay[690]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 54436
13:49:50 media-relay[690]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 54437
13:49:50 media-relay[690]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 54438
13:49:50 media-relay[690]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 54439
13:49:50 media-relay[690]: debug: Added new stream: (audio)
100.3.4.5:60846 (RTP: Unknown, RTCP: Unknown) <-> 90.1.2.3:54436 <->
90.1.2.3:54438 <-> Unknown (RTP: Unknown, RTCP: Unknown)
13:49:50 media-relay[690]: debug: created new session
some-call...@80.2.3.5: 0212345...@80.2.3.5 (69D9B578-1DC8) -->
0276543...@outbound.tld

# Both devices are ringing:

13:49:50 OpenSIPS[769]: Reply - S=100 D=Trying F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=111.2.3.4:61000 id=some-call...@80.2.3.5
13:49:50 OpenSIPS[771]: Reply - S=180 D=Ringing
F=sip:0212345...@80.2.3.5 T=sip:0276543...@outbound.tld
SRC=111.2.3.5:51076 id=some-call...@80.2.3.5
13:49:50 OpenSIPS[757]: Reply - S=180 D=Ringing
F=sip:0212345...@80.2.3.5 T=sip:0276543...@outbound.tld
SRC=111.2.3.4:61000 id=some-call...@80.2.3.5

# Timeout happens, 60 secs are over, call is redirected to VM Server,
# the two active branches are cancelled

13:50:51 OpenSIPS[779]: Request leaving server in transaction - M=INVITE
RURI=sip:12...@vm.mydomain.tld F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5
13:50:51 OpenSIPS[776]: Reply - S=100 D=Trying F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=90.1.2.1:5060 id=some-call...@80.2.3.5
13:50:51 OpenSIPS[758]: Reply - S=487 D=Request Terminated
F=sip:0212345...@80.2.3.5 T=sip:0276543...@outbound.tld
SRC=111.2.3.5:51076 id=some-call...@80.2.3.5
13:50:51 OpenSIPS[767]: Reply - S=487 D=Request Cancelled
F=sip:0212345...@80.2.3.5 T=sip:0276543...@outbound.tld
SRC=111.2.3.4:61000 id=some-call...@80.2.3.5

# VM Server waits 1 additional second and then picks up the call (early
# media):

13:50:52 OpenSIPS[770]: Reply - S=183 D=Session Progress
F=sip:0212345...@80.2.3.5 T=sip:0276543...@outbound.tld
SRC=90.1.2.1:5060 id=some-call...@80.2.3.5
13:50:52 media-dispatcher[1697]: debug: Issuing "update" command to
relay at 90.1.2.3

# The update reaches the relay - no RTP info yet:

13:50:52 media-relay[690]: debug: Got traffic information for stream:
(audio) 100.3.4.5:60846 (RTP: Unknown, RTCP: Unknown) <-> 90.1.2.3:54436
<-> 90.1.2.3:54438 <-> Unknown (RTP: 90.1.2.1:10262, RTCP: Unknown)
13:50:52 media-relay[690]: debug: updating existing session
some-call...@80.2.3.5: 0212345...@80.2.3.5 (69D9B578-1DC8) -->
0276543...@outbound.tld
13:50:52 media-relay[690]: debug:

[OpenSIPS-Users] Mediaproxy - timeout issue if ringing for more than 60 seconds

[Thomas Gelf]

Hi list,

there must be a hidden timeout between the initial INVITE and the first
provisional response with SDP - it seems to equal 60 seconds. Therefore
you hear nothing if you pick up your call after 60 seconds. I tried to
document a whole call, going to Voicemail after 61 seconds. While doing
my tests I also played around with some undocumented setting, without
success (relay_recover_interval).

Here the call trace (please note that the same call is fine if VM picks
up the call within 60 seconds):

# Call from PSTN (0212345678) to local user (0276543210,
# my-u...@mydomain.tld, vmbox: 12345):

13:49:50 OpenSIPS[762]: New dialog from trusted peer - M=INVITE
RURI=sip:0276543...@my.proxy.tld F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5
13:49:50 OpenSIPS[762]: Callee was aliased, PSTN - M=INVITE
RURI=sip:my-u...@mydomain.tld F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5
13:49:50 OpenSIPS[762]: Setting ring timeout to 60 secs - M=INVITE
RURI=sip:my-u...@mydomain.tld F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5

# Two branches are forked, however there is only one of them in my logs
# (need to move that xlog()-statement to branch_route):

13:49:50 OpenSIPS[762]: Local user online - M=INVITE
RURI=sip:my-u...@10.0.0.10:1025;line=iqdxv6hz F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5
13:49:50 OpenSIPS[762]: Request leaving server,
D-URI='sip:111.2.3.5:51076' - M=INVITE
RURI=sip:my-u...@10.0.0.10:1025;line=iqdxv6hz F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5
13:49:50 media-dispatcher[1697]: debug: Issuing "update" command to
relay at 90.1.2.3

# On one of the relay hosts the call is prepared:

13:49:50 media-relay[690]: debug: Received new SDP offer
13:49:50 media-relay[690]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 54436
13:49:50 media-relay[690]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 54437
13:49:50 media-relay[690]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 54438
13:49:50 media-relay[690]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 54439
13:49:50 media-relay[690]: debug: Added new stream: (audio)
100.3.4.5:60846 (RTP: Unknown, RTCP: Unknown) <-> 90.1.2.3:54436 <->
90.1.2.3:54438 <-> Unknown (RTP: Unknown, RTCP: Unknown)
13:49:50 media-relay[690]: debug: created new session
some-call...@80.2.3.5: 0212345...@80.2.3.5 (69D9B578-1DC8) -->
0276543...@outbound.tld

# Both devices are ringing:

13:49:50 OpenSIPS[769]: Reply - S=100 D=Trying F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=111.2.3.4:61000 id=some-call...@80.2.3.5
13:49:50 OpenSIPS[771]: Reply - S=180 D=Ringing
F=sip:0212345...@80.2.3.5 T=sip:0276543...@outbound.tld
SRC=111.2.3.5:51076 id=some-call...@80.2.3.5
13:49:50 OpenSIPS[757]: Reply - S=180 D=Ringing
F=sip:0212345...@80.2.3.5 T=sip:0276543...@outbound.tld
SRC=111.2.3.4:61000 id=some-call...@80.2.3.5

# Timeout happens, 60 secs are over, call is redirected to VM Server,
# the two active branches are cancelled

13:50:51 OpenSIPS[779]: Request leaving server in transaction - M=INVITE
RURI=sip:12...@vm.mydomain.tld F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=80.2.3.4:5060 id=some-call...@80.2.3.5
13:50:51 OpenSIPS[776]: Reply - S=100 D=Trying F=sip:0212345...@80.2.3.5
T=sip:0276543...@outbound.tld SRC=90.1.2.1:5060 id=some-call...@80.2.3.5
13:50:51 OpenSIPS[758]: Reply - S=487 D=Request Terminated
F=sip:0212345...@80.2.3.5 T=sip:0276543...@outbound.tld
SRC=111.2.3.5:51076 id=some-call...@80.2.3.5
13:50:51 OpenSIPS[767]: Reply - S=487 D=Request Cancelled
F=sip:0212345...@80.2.3.5 T=sip:0276543...@outbound.tld
SRC=111.2.3.4:61000 id=some-call...@80.2.3.5

# VM Server waits 1 additional second and then picks up the call (early
# media):

13:50:52 OpenSIPS[770]: Reply - S=183 D=Session Progress
F=sip:0212345...@80.2.3.5 T=sip:0276543...@outbound.tld
SRC=90.1.2.1:5060 id=some-call...@80.2.3.5
13:50:52 media-dispatcher[1697]: debug: Issuing "update" command to
relay at 90.1.2.3

# The update reaches the relay - no RTP info yet:

13:50:52 media-relay[690]: debug: Got traffic information for stream:
(audio) 100.3.4.5:60846 (RTP: Unknown, RTCP: Unknown) <-> 90.1.2.3:54436
<-> 90.1.2.3:54438 <-> Unknown (RTP: 90.1.2.1:10262, RTCP: Unknown)
13:50:52 media-relay[690]: debug: updating existing session
some-call...@80.2.3.5: 0212345...@80.2.3.5 (69D9B578-1DC8) -->
0276543...@outbound.tld
13:50:52 media-relay[690]: debug: Received updated SDP answer
13:50:52 media-relay[690]: debug: Got initial answer from callee for
stream: (audio) 100.3.4.5:60846 (RTP: Unknown, RTCP: Unknown) <->
90.1.2.3:54436 <-> 90.1.2.3:54438 <-> 90.1.2.1:10262 (RTP:
90.1.2.1:10262, RTCP: Unknown)

# Traffic starts in one direction, however I'm unable to hear something:

13:50:57 m

Re: [OpenSIPS-Users] Quota system problem

[Adrian Georgescu]

What happens when you run it? What is displayed in the syslog?

Adrian

On Jun 19, 2009, at 11:07 AM, ASHWINI NAIDU wrote:


hi Adrian,

I am running it in cron job every minute. but the user is not  
added to quota group at all. even the quota_)usage is not getting  
populated




On Fri, Jun 19, 2009 at 2:09 PM, Adrian Georgescu projects.com> wrote:

You must run this script for anything to happen:

/var/www/CDRTool/scripts/OpenSIPS/quotaCheck.php

Visit syslog to see what happens while running it.

Adrian



On Jun 19, 2009, at 10:07 AM, ASHWINI NAIDU wrote:

hi all,

  I have installed opensips1.5,radius-2.1.4 and CDRTool-6.7.7. I am  
trying to workout quota for postpaid users. I have added the quota  
column in opensips.subscriber table. When the postpaid user makes a  
call the usage information is not inserted in quota_usage. Even if  
the quota for the month is over the user is not added to the quota  
group in opensips.grp. I am running only quotaCheck.php script in  
the cron job.


can anyone help me out with this problem or can anyone give me more  
information on quota system of cdrtool.


--
Thanking You,
Ashwini BR Naidu
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




--
Thanking You,
Ashwini BR Naidu


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

[OpenSIPS-Users] Dispatcher module round-robin trouble

[Josip Djuricic]

I've just tried dispatcher module and I'm having oneq uestionRound-robin
method (algorithm nr. 4) seams not to work correctly, I'm receiving a lot of
errors with it, and if I use any other algorithm everything works perfectly.

 

But I would really like to test round-robin model.

 

Best regards,

 

Josip

 

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

[OpenSIPS-Users] Call-forward and multi-leg accounting

[Carlo Dimaggio]

Hi all,

I'm trying to implement a call-forward-unconditional with radius multi- 
leg accounting.
The multileg acc parameter is: modparam("acc", "multi_leg_info",  
"Calling-Station-Id=$avp(s:cwd_src);Called-Station-Id= 
$avp(s:cwd_dst)"), while in the request route I have this test block:

$avp(s:cfu)="sip:1...@sip.xxx.it";
avp_pushto("$ruri", "$avp(s:cfu)");
append_branch();
$avp(s:cwd_src)="sip:1...@sip.xxx.it";
$avp(s:cwd_dst)="sip:1...@sip.xxx.it";

The test call is: 1000 -> 1002 -> redirected to 1001

My aim is to have two radius accounting messages but I have only one  
accouting message with the multi_leg_info attached. Indeed I have seen  
in the documentation that this should be the normal behaviour when  
radius is used.

Is there any way to achive my aim (two invite, one from 1000 to 1002  
and one from 1002 to 1001)?


Thank you,
Carlo Dimaggio



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

Re: [OpenSIPS-Users] Load balancer module

[Josip Djuricic]

Hi,

Ofcourse, I can send you this from yesterday log:

Sorry I removed IP because of the obvious reasons.

Jun 18 10:57:33 b2bua-rlf /usr/local/sbin/opensips[29756]: Selected
destination is: sip:xxx.xxx.xxx.xxx:3


Btw. Is there a possibility to choose destination based on cps rate?

Best regards,

Josip

-Original Message-
From: Bogdan-Andrei Iancu [mailto:bog...@voice-system.ro] 
Sent: Friday, June 19, 2009 9:29 AM
To: Josip Djuricic
Cc: 'Brett Nemeroff'; users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Load balancer module

Hi Josip,

could you print the $du variable after you successfully do load_balance() ?

like add :
xlog(" new destination is %du \n");

and see if the printed URI does contain the port part also ?

Regards,
Bogdan

Josip Djuricic wrote:
> Hi,
>
> Since we are at load_balancer module I've noticed one strange behaviour on
> trunk and 1.5.0 version also.
>
> I see that every request is sent to port 5060 no matter what I've put in
> dst_uri field...i.e. if I put sip:xxx.xxx.xxx.xxx:port_number, it will
still
> send everything to port 5060 instead of defined port_number, ofcourse
> looping itself if opensips is on port 5060 on the same ip.
>
> I've tried this with the example from the web, so perhaps I am doing
> something wrong?
>
> Best regards,
>
> Josip
>
>
>
>
> -Original Message-
> From: users-boun...@lists.opensips.org
> [mailto:users-boun...@lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
> Sent: Friday, June 19, 2009 9:12 AM
> To: Brett Nemeroff
> Cc: users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] Load balancer module
>
> HI Brett,
>
> Brett Nemeroff wrote:
>   
>> All,
>> What's the actual status of the load balancer module? I see in 1.5 
>> it's alpha/NEW. Is it usable yet?
>> 
> alpha means in not 100% tested (but does not mean is not stable). Also 
> it means that devel is still on progress as I plan to add some more 
> features on it/
>   
>> I don't know how conservative those labels are.
>> 
> as much as possible :)
>
> Regards,
> Bogdan
>   
>> -Brett
>>
>> 
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>   
>> 
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>   



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

Re: [OpenSIPS-Users] SIP CLient <- TLS --> OpenSIPS <- UDP -> SIP Server

[Anil M Pannikode (hotmail)]

We are still not able to get TLS working. The OpsnSIPS logs shows the
following

Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:parse_to:
display={"Anonymous"}, ruri={sip:anonym...@sip1.mydomain.com} 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: Method : INVITE
from 10.10.20.246 fd sip1.mydomain.com 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:maxfwd:is_maxfwd_present: value = 70  
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:tm:t_newtran:
transaction on entrance=0x 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:parse_headers: flags= 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:parse_to_param: tag=77243246313536411E34 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:parse_to:
end of header reached, state=29 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:parse_to:
display={}, ruri={sip:999...@ipgateway.mydomain.com;user=phone} 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:get_hdr_field:  [86];
uri=[sip:999...@ipgateway.mydomain.com;user=phone]  
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:get_hdr_field: to body
[] 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:get_hdr_field: cseq : <2>  
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:get_hdr_field: content_length=401 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:get_hdr_field: found end of header 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:parse_headers: flags=78 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:t_lookup_request: start searching: hash=39696, isACK=0 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:matching_3261: RFC3261 transaction matching failed 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:t_lookup_request: no transaction found 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:run_reqin_callbacks: trans=0xb40250e8, callback type 1, id 0 entered 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:parse_headers: flags= 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:check_via_address: params 10.10.20.246, 10.10.20.246, 0 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:_shm_resize: resize(0) called 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:_reply_light: reply sent out. buf=0x82a30c0: SIP/2.0 1...,
shmem=0xb40141c8: SIP/2.0 1 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:tm:_reply_light: finished 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:mk_proxy:
doing DNS lookup... 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:parse_headers: flags=2000 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:tcp_send:
no open tcp connection found, opening new one 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:print_ip:
tcpconn_new: new tcp connection to: 10.10.20.206 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tcpconn_new: on port 5061, type 3 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_tcpconn_init: entered: Creating a whole new ssl connection 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_tcpconn_init: TLS client domain AVP found = 'sip1.mydomain.com'

Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_find_client_domain_name: virtual TLS client domain found 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_tcpconn_init: found name based TLS client domain
'sip1.mydomain.com' 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_tcpconn_init: Setting in CONNECT mode (client) 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:tcp_send:
sending... 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
DBG:core:tls_update_fd: New fd is 8 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]:
ERROR:core:tls_blocking_write: too many retries with no operation 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:tcp_send:
after write: c= 0xb40284d8 n=-1 fd=8 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2114]:
DBG:core:handle_ser_child: read response= b40284d8, 2, fd 25 from 1 (2103) 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2114]:
DBG:core:tcpconn_add: hashes: 463, 36 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2114]:
DBG:core:io_watch_add: io_watch_add(0x826a9c0, 25, 2, 0xb40284d8), fd_no=17 
Jun 17 03:41:23 sip-proxy-dev2 /usr/sbin/opensips[2103]: DBG:core:tcp_send:
buf= INVITE sip:999...@10.10.20.206:5061;transport=tls SIP/2.0^M Via:
SIP/2.0/TLS 10.10.10.193:5061;branch=z9hG4bK01b9.1a760103.0^M Via:
SIP/2.0/UDP
10.10.20.246:5060;received=10.10.20.246;rport=5060;branch=z9hG4bK3270876536-
394448^M Route:
,^M Max-Forwards: 69^M 

Re: [OpenSIPS-Users] Quota system problem

[ASHWINI NAIDU]

hi Adrian,

I am running it in cron job every minute. but the user is not added to
quota group at all. even the quota_)usage is not getting populated



On Fri, Jun 19, 2009 at 2:09 PM, Adrian Georgescu wrote:

> You must run this script for anything to happen:
>
> /var/www/CDRTool/scripts/OpenSIPS/quotaCheck.php
>
> Visit syslog to see what happens while running it.
>
> Adrian
>
>
>
> On Jun 19, 2009, at 10:07 AM, ASHWINI NAIDU wrote:
>
>  hi all,
>>
>>   I have installed opensips1.5,radius-2.1.4 and CDRTool-6.7.7. I am trying
>> to workout quota for postpaid users. I have added the quota column in
>> opensips.subscriber table. When the postpaid user makes a call the usage
>> information is not inserted in quota_usage. Even if the quota for the month
>> is over the user is not added to the quota group in opensips.grp. I am
>> running only quotaCheck.php script in the cron job.
>>
>> can anyone help me out with this problem or can anyone give me more
>> information on quota system of cdrtool.
>>
>> --
>> Thanking You,
>> Ashwini BR Naidu
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>


-- 
Thanking You,
Ashwini BR Naidu
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] pua_xmpp sip-xmpp gateway setup help

[Anca Vamanu]

Hi Mani,

After googleing up your error returned by ejabber  I think that the 
problem is that the domain of the xmpp buddy is not the same as the 
domain you configured to ejabber. I see in your post that you say that 
the xmpp server domain in xmpp.smsi.com but in the message the to uri 
has domain dsdev-xmpp.smsi.com.

regards,
Anca

mani sivaraman wrote:
> I see the following XMPP message communication debug from opensips 
> server console. The opensips gets a 400 error for sending the xmpp 
> message to openfire.
>
>
> Jun 18 14:28:48 [26322] DBG:xmpp:xmpp_component_child_process: got 
> pipe cmd 2
> Jun 18 14:28:48 [26322] DBG:xmpp:do_send_message_component: 
> do_send_message_component from=[sip:msivara...@sips01.smithmicro.com 
> ] 
> to=[sip:mani_openfire*dsdev-xmpp.smsi.com 
> @sip-xmpp.smithmicro.com 
> ] body=[hi]
> Jun 18 14:28:48 [26322] DBG:xmpp:xode_send: xode_send [ id='smsiUA_372474835-534838778' from='msivaraman*sips01.smithmicro.com 
> @xmpp-sip.smithmicro.com 
> ' 
> to='mani_openf...@dsdev-xmpp.smsi.com 
> ' 
> type='chat'>hi]
> Jun 18 14:28:48 [26322] DBG:xmpp:xmpp_component_child_process: server read
> [ from='mani_openf...@dsdev-xmpp.smsi.com 
> ' 
> id='smsiUA_372474835-534838778'>hi type='modify'> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>]
>
> Could any one please help.
>
>
> On Thu, Jun 18, 2009 at 2:43 PM, mani sivaraman 
> mailto:mani.opens...@gmail.com>> wrote:
>
> I have the full detailed debug console out of opensips, while
> trying to add an xmpp buddy to my sip client connected to
> opensips. Seems like I get the NOTIFY for the new xmpp buddy
> added, but blank xml body. The message is not reaching the
> openfire xmpp clinet.
>
> Could any one look at the output log and tell me what is missing ?
> Thanks you very much
>
>
>
> On Thu, Jun 18, 2009 at 10:56 AM, mani sivaraman
> mailto:mani.opens...@gmail.com>> wrote:
>
> I'm new to opensips. I'm trying to setup sip-xmpp gateway
> using the "component" mode with a local ejabbered server. I
> followed the opensips.cfg found in link
>
> http://www.opensips.org/Resources/PuaXmppConfig
>
> I have 3 domains defined for my opensips server.
>
> sips01.mydomain.com  - primary
> opensips dns/domain defined in my sql doamin table
> sip-xmpp.mydoamin.com  - for
> gateway sip domain
> xmpp.mydomain.com   - for xmpp
> server
> xmpp-sip.mydomain.com  - for
> xmpp component of opensips
>
> I have configured the same according to the link. config above.
>
> I have all these 4 domain in /etc/hosts file. The first
> primary domain is the only one on dns look up.
>
> I have ejabbered server listenening on port 5347, I also see
> my opensips ESTABLISHED connetion to port 5347 of ejabbered.
>
> Testing:
> 
> I logged into opensips with a sip/presence client and added an
> xmpp buddy to the sip contact list with the following format.
> The xmpp buddy is on an openfire server.
> so the buddy added was like
>
> mani_openfire*openfire.mydomain.com
> @sip-xmpp.mydomain.com
> 
>
> I see opensips sending SUBSCRIBE to mani_openfire and got
> NOTIFY for the same. But there is no body in the NOTIFY. Says
> subscription state = active. I do not see any communication to
> the openfire server however, if I do a tcpdump.
>
> When I try to send a message to the openfire buddy, I get 200
> OK, but the MESSAGE never gets through to the openfire server
> buddy.
>
> I'm attaching the opensips.cfg for ref. Could any one please
> point out what I'm doing wrong. I do not seeing any error when
> testing. Still MESSAGE is not working bet sip and xmpp.
>
>
>
> 
>
> ___
> 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] limit number of outbound calls using DIALOG

[Alex Balashov]

Use a dialog profile.  Use $fu as the key ("value").  Check if profile 
size is > 1, refuse the call.

That's what they're there for.

Jayesh Nambiar wrote:

> Hi,
> I am looking at an option to limit more than one call per user even if 
> they are registered from multiple locations.
> Basically if User A calls from location A and if the call is active, 
> User A registered from location B should not be allowed to make a call. 
> What I did was:
> 
> 1) Create a dialog after every initial INVITE initiated by users
> 2) Before creating the dialog, query the dialog table to check if $fu 
> has an entry in the dialog table using avp_db_query.
> 3) If yes, means user A is already on a call so send a 403, Forbidden.
> 4) Else, create the dialog and process call.
> 
> Although this works, i just wonder if doing avp_db_query everytime to 
> check if the caller has a call active is an efficient way of doing it??
> Is it possible to store these dialog parameters in localcache using 
> memcache module or access the dialog parameters from memory and compare 
> it with the INVITE messages !!!
> 
> Just trying to find a more efficient way of achieving this.
> 
> Thanks for any inputs you might have !!
> 
> --- Jay
> 
> 
> 
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

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

[OpenSIPS-Users] limit number of outbound calls using DIALOG

[Jayesh Nambiar]

Hi,I am looking at an option to limit more than one call per user even if
they are registered from multiple locations.
Basically if User A calls from location A and if the call is active, User A
registered from location B should not be allowed to make a call. What I did
was:

1) Create a dialog after every initial INVITE initiated by users
2) Before creating the dialog, query the dialog table to check if $fu has an
entry in the dialog table using avp_db_query.
3) If yes, means user A is already on a call so send a 403, Forbidden.
4) Else, create the dialog and process call.

Although this works, i just wonder if doing avp_db_query everytime to check
if the caller has a call active is an efficient way of doing it??
Is it possible to store these dialog parameters in localcache using memcache
module or access the dialog parameters from memory and compare it with the
INVITE messages !!!

Just trying to find a more efficient way of achieving this.

Thanks for any inputs you might have !!

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

Re: [OpenSIPS-Users] Media Proxy 2.x with Openser 1.3.4

[Dan Pascu]

On 19 Jun 2009, at 11:40, Matteo Piazza wrote:

> Sorry Dan I miss the point,
>
> do you mean that I have to compile the mediaproxy module of opensips  
> and use it with openser 1.3 or simply are you saing that to use  
> mediaproxy I have to use the mediaproxy module of 1.3 version.
>

The former.

> Matteo
>
> Dan Pascu ha scritto:
>>
>> On 19 Jun 2009, at 11:17, Matteo Piazza wrote:
>>
>>> I would like to know if I can use Media Proxy 2.x series with  
>>> Openser
>>> 1.3.4? I have a Openser 1.3.4 in a production enviroment so in this
>>> moment I don't wanna migrate to opensips immediatly but only add  
>>> Media
>>> proxy to my installation.
>>
>>
>> You can if you port the mediaproxy module to 1.3
>>
>> -- 
>> Dan
>>
>>
>>
>
>
> -- 
> = 
> = 
> = 
> = 
> ==
> Matteo Piazza
> Trentino Network s.r.l.
> Area Innovazione
> Via Gilli, 2 - 38100 TRENTO
> Tel (+39) 0461.020224
> Mob (+39) 335.5378482
> Fax (+39) 0461.020201
> Cap. Soc. sottoscritto  7.573.248,00 - i. v.
> REG. IMP. C.F. e P. IVA 01904880224
> Società soggetta a direzione e controllo da parte della Provincia
> Autonoma di Trento. C.F. e P. IVA 00337460224
> = 
> = 
> = 
> = 
> ==
>


--
Dan




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

Re: [OpenSIPS-Users] Media Proxy 2.x with Openser 1.3.4

[Matteo Piazza]

Sorry Dan I miss the point,

do you mean that I have to compile the mediaproxy module of opensips and 
use it with openser 1.3 or simply are you saing that to use mediaproxy I 
have to use the mediaproxy module of 1.3 version.

Matteo

Dan Pascu ha scritto:
>
> On 19 Jun 2009, at 11:17, Matteo Piazza wrote:
>
>> I would like to know if I can use Media Proxy 2.x series with Openser
>> 1.3.4? I have a Openser 1.3.4 in a production enviroment so in this
>> moment I don't wanna migrate to opensips immediatly but only add Media
>> proxy to my installation.
>
>
> You can if you port the mediaproxy module to 1.3
>
> -- 
> Dan
>
>
>


-- 
==
Matteo Piazza
Trentino Network s.r.l.
Area Innovazione
Via Gilli, 2 - 38100 TRENTO
Tel (+39) 0461.020224
Mob (+39) 335.5378482
Fax (+39) 0461.020201
Cap. Soc. sottoscritto  7.573.248,00 - i. v.
REG. IMP. C.F. e P. IVA 01904880224
Società soggetta a direzione e controllo da parte della Provincia
Autonoma di Trento. C.F. e P. IVA 00337460224
==


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

Re: [OpenSIPS-Users] Quota system problem

[Adrian Georgescu]

You must run this script for anything to happen:

/var/www/CDRTool/scripts/OpenSIPS/quotaCheck.php

Visit syslog to see what happens while running it.

Adrian


On Jun 19, 2009, at 10:07 AM, ASHWINI NAIDU wrote:

> hi all,
>
>I have installed opensips1.5,radius-2.1.4 and CDRTool-6.7.7. I am  
> trying to workout quota for postpaid users. I have added the quota  
> column in opensips.subscriber table. When the postpaid user makes a  
> call the usage information is not inserted in quota_usage. Even if  
> the quota for the month is over the user is not added to the quota  
> group in opensips.grp. I am running only quotaCheck.php script in  
> the cron job.
>
> can anyone help me out with this problem or can anyone give me more  
> information on quota system of cdrtool.
>
> -- 
> Thanking You,
> Ashwini BR Naidu
> ___
> 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] LDAP Authentication

[Gavin Henry]

This is why I submitted a feature request for the ldap_sasl_bind
function to be added. Then a sucessful bind is all that is needed by
opensips. The problem is converting the password to plain on the
opensips side to use it to bind with against the ldap directory. Is
this possible?

That way, we know the digest format in sip, but we don't need to care
about the ldap hash format (most are ssha1) *and* we don't need to
change the directory.

On 19/06/2009, Bogdan-Andrei Iancu  wrote:
> Alan,
>
> Could you post the part of the script taking care of the REGISTRATION
> part, just for double checking ?
>
> Also, for the password...does not look ok - not sure how that value is
> computed, but please check the Digest Auth RFC to see the definition of
> HA1 .
>
> Regards,
> Bogdan
>
>
>
> Alan Rubin wrote:
>> (reposting to fit the list size limits)
>>
>> Bogdan,
>>
>> 2) I removed the "!" from the REGISTER section.  This seems to have at
>> least pushed me on to the next stage of actually doing an LDAP query:
>>
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:ldap:ldap_url_search: LDAP URL parsed into session_name
>> [sipaccounts], base [o=ntg], scope [2], filter
>> [(&(cn=oh5)(departmentNumber=66)(ntguserstatus=Active))]
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:ldap:lds_search: [sipaccounts]: performing LDAP search: dn [o=ntg],
>> scope [2], filter
>> [(&(cn=oh5)(departmentNumber=66)(ntguserstatus=Active))], client_timeout
>> [500] usecs
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:ldap:ldap_params_search: [sipaccounts]: [1] LDAP entries found
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:auth:check_nonce: comparing
>> [4a3ae9d1b43a57f1ad95192b98ace5030eb50d1a] and
>> [4a3ae9d1b43a57f1ad95192b98ace5030eb50d1a]
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:auth:reserve_nonce_index: second= 12, sec_monit= -1,  index= 2
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:auth:build_auth_hf: nonce index= 2
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:auth:build_auth_hf: 'Proxy-Authenticate: Digest
>> realm="155.205.69.126",
>> nonce="4a3ae9d2c65c88df6909b9e945bdbaaa5e495b3a"  '
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:core:parse_headers: flags=
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:core:check_via_address: params 155.205.26.124, 155.205.26.124, 0
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:core:destroy_avp_list: destroying list (nil)
>> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
>> DBG:core:receive_msg: cleaning up
>> ...
>>
>> Still failing, but this time it is code 407: Proxy Authentication
>> Required.  Getting closer?
>>
>> 1) Perhaps I mean "encoded" and am just using the wrong term.  An
>> example return from our LDAP search:
>>  userPassword: {SSHA}twmolvRuvt11fr4GVJOxIasfcGi6yci9LIEfaUQ==
>>
>> Regards,
>>
>> Alan Rubin
>>
>> -Original Message-
>> From: Bogdan-Andrei Iancu [mailto:bog...@voice-system.ro]
>> Sent: Friday, 19 June 2009 10:52 AM
>> To: Alan Rubin
>> Cc: users@lists.opensips.org
>> Subject: Re: [OpenSIPS-Users] LDAP Authentication
>>
>> Alan,
>>
>> 2 points:
>>
>> 1) what you mean by "encrypted" ? the module supports only ha1 encoded
>> passwords.
>>
>> 2) I see you deal with a REGISTER request, but in your script you
>> changed the auth (from DB to LDAP) only for INVITES - check in the
>> script the second auth block (for REGISTERS) and change it in the same
>> time as we did for the INVITEs.
>>
>> Regards,
>> Bogdan
>>
>> Alan Rubin wrote:
>>
>>> Bogdan,
>>>
>>> Thanks for your help.  I reset the configuration for calculate_ha1 to
>>>
>> 0
>>
>>> (it was set to 1), but I am still getting a "401 - Unauthorized"
>>>
>> error.
>>
>>> The password returning from the LDAP server should be an encrypted
>>> string.
>>>
>>> # - auth_db params -
>>> /* uncomment the following lines if you want to enable the DB based
>>>authentication */
>>> #modparam("auth_db", "calculate_ha1", yes)
>>> #modparam("auth_db", "password_column", "password")
>>> #modparam("auth_db", "db_url",
>>> #   "mysql://opensips:@localhost/opensips")
>>> #modparam("auth_db", "load_credentials", "")
>>>
>>> # -- auth params -
>>> #modparam("auth", "username_spec", "$var(username)")
>>> #modparam("auth", "password_spec", "$avp(s:password)")
>>> modparam("auth", "nonce_expire",  30)
>>> modparam("auth", "secret", "")
>>> modparam("auth", "disable_nonce_check", 0)
>>> modparam("auth", "username_spec", "$var(username)")
>>> modparam("auth", "password_spec", "$avp(s:password)")
>>> modparam("auth", "calculate_ha1", 0)
>>>
>>> Here are the relevant logs from the connection (I think):
>>>
>>>
>>>
>
>
> __

Re: [OpenSIPS-Users] Media Proxy 2.x with Openser 1.3.4

[Dan Pascu]

On 19 Jun 2009, at 11:17, Matteo Piazza wrote:

> I would like to know if I can use Media Proxy 2.x series with Openser
> 1.3.4? I have a Openser 1.3.4 in a production enviroment so in this
> moment I don't wanna migrate to opensips immediatly but only add Media
> proxy to my installation.


You can if you port the mediaproxy module to 1.3

--
Dan




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

[OpenSIPS-Users] Media Proxy 2.x with Openser 1.3.4

[Matteo Piazza]

I would like to know if I can use Media Proxy 2.x series with Openser
1.3.4? I have a Openser 1.3.4 in a production enviroment so in this
moment I don't wanna migrate to opensips immediatly but only add Media
proxy to my installation.

Thanks Matteo.

-- 
==
Matteo Piazza
Trentino Network s.r.l.
Area Innovazione
Via Gilli, 2 - 38100 TRENTO
Tel (+39) 0461.020224
Mob (+39) 335.5378482
Fax (+39) 0461.020201
Cap. Soc. sottoscritto  7.573.248,00 - i. v.
REG. IMP. C.F. e P. IVA 01904880224
Società soggetta a direzione e controllo da parte della Provincia
Autonoma di Trento. C.F. e P. IVA 00337460224
==



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

[OpenSIPS-Users] opensips-1.5.1 postgres tables error

[Matteo Piazza]

I found an issue using opensips-1.5.1-notls.

When I try to create the tables for a postgres database (8.3 version) on 
a debian 5.0 I have the following error:


# opensipsdbctl create
INFO: creating database opensips ...
NOTICE:  CREATE TABLE / UNIQUE will create implicit index 
"version_t_name_idx" for table "version"



NOTICE:  CREATE TABLE will create implicit sequence 
"load_balancer_id_seq" for serial column "load_balancer.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"load_balancer_pkey" for table "load_balancer"
ERROR:  relation "dr_gateways_id_seq" does not exist
ERROR:  relation "dr_gateways_id_seq" does not exist
ERROR: Grant privileges to standard tables failed!

If i try to create the table on a mysql database on the same machine and 
with the same compilate version everithing is fine.
If I try to create the table on the same postgres database with openser 
1.3.4 everything is fine.

Kind Regards
Matteo

-- 
==
Matteo Piazza
Trentino Network s.r.l.
Area Innovazione
Via Gilli, 2 - 38100 TRENTO
Tel (+39) 0461.020224
Mob (+39) 335.5378482
Fax (+39) 0461.020201
Cap. Soc. sottoscritto  7.573.248,00 - i. v.
REG. IMP. C.F. e P. IVA 01904880224
Società soggetta a direzione e controllo da parte della Provincia
Autonoma di Trento. C.F. e P. IVA 00337460224
==


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

[OpenSIPS-Users] Quota system problem

[ASHWINI NAIDU]

hi all,

   I have installed opensips1.5,radius-2.1.4 and CDRTool-6.7.7. I am trying
to workout quota for postpaid users. I have added the quota column in
opensips.subscriber table. When the postpaid user makes a call the usage
information is not inserted in quota_usage. Even if the quota for the month
is over the user is not added to the quota group in opensips.grp. I am
running only quotaCheck.php script in the cron job.

can anyone help me out with this problem or can anyone give me more
information on quota system of cdrtool.

-- 
Thanking You,
Ashwini BR Naidu
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] call_control module problem

[Dan Pascu]

On 19 Jun 2009, at 04:30, Konstantin wrote:

> Hi there!
>
> I have this piece in the config script:
>
> ...
> call_control();
> xlog("=== call_control: $$retcode = $retcode\n");
> switch ($retcode) {
>case 2:
>xdbg("=== call_control: Call with no limit\n");
>break;
>case 1:
>xdbg("=== call_control: Call has limit and is under  
> callcontrol management\n");
>break;
> ...
>
>
> And something like this I have in the debug output:
>
> Jun 19 01:03:21 [2058] ERROR:call_control:send_command: did timeout  
> waiting for an answer
> === call_control: $retcode = 4294967291
> === call_control: Call has limit and is under callcontrol management
>
>
> So why 4294967291 works like "case 1" ("under callcontrol  
> management")  in case of timeout on
> external application?
>

Because $retcode has to be used right after the function that  
generated it. xlog is a function as well and it'll generate its own  
return code when called, overwriting the previous value.

> I would like to have "Internal server error" in case of timeout.
>
>
>
>
>
>
>
> -- 
> Konstantin
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan




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

Re: [OpenSIPS-Users] update location table on REGISTER request

[Bogdan-Andrei Iancu]

I seeIdeally we could allow control append_branch per user, but not 
possible right now.

What can be done is to allow append_branch for all of them and to simply 
purge the added branches for the users with only one contact 
registration. If it is a hack, use serialize_branches() function to 
delete the additional branches added by lookup(location) (actually the 
function moves the branches in some AVPS, but the important part is that 
the branches are cleaned :) ).

Regards,
Bogdan

Jayesh Nambiar wrote:
> Thank you Bogdan, for the correct approach explained.
> But the append branch then applies to all users right? What i was 
> trying to do here was:
> 1) Allow some basic users to have only one registration contact possible.
> 2) Allow premium users to have as many contacts possible and receive 
> calls on any of the location.
>
> Based upon certain conditions can i increase the append branch 
> parameter after looking up location and before relaying !!!
> Just a thought.
>
> --- Jay
>
> On Fri, Jun 19, 2009 at 12:38 PM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> HI Jayesh,
>
> What you could do is to accept 2-3 registrations, but to actually
> use the last one only.
>
> So set the mac_contacts to 2 or 3, the append_branches to 0 (to
> use only one contact) and in usrloc module set desc_time_order to
> 1
> (http://www.opensips.org/html/docs/modules/1.5.x/usrloc.html#id266565)
> to sort contacts based on the registration time (first used will
> be the last registered)
>
> Regards,
> Bogdan
>
> Jayesh Nambiar wrote:
>
> Hi All,
> I had a requirement of allowing only one registration per user
> in a particular scenario. I did not want to use the
> max_contacts parameter of registrar module as it wont work
> right !!! The drawback was:
> If device A had registered successfully and for some reason
> got disconnected from the internet, the device won't
> unregister itself. Opensips still has the record in the
> location table for that device, now if the internet comes back
> and when the device tries to register again, opensips will not
> allow since it already has the record in the location.
> The device will have to wait until the earlier registration
> expires in the opensips.
> The idea was to have a way of updating the location table if
> same user is trying to REGISTER from same location or
> different location. Meaning if user A is registered from
> location A and someone else using same credentials of user A
> tries to register from location B, the location table should
> only update the earlier record to location B and not keep
> location A and location B both for user A.
>
> Is there a way to do this. Any help will be highly appreciiated.
>
> Thanks in advance.
>
> --- Jay
> 
> 
>
> ___
> 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] Basic call failed

[XIN Xiuhe]

Hi, uwe, 

Great, it is ok.
Thanks for your help!  

-Original Message-
From: Uwe Kastens [mailto:ki...@kiste.org] 
Sent: 2009年6月19日 15:23
To: XIN Xiuhe
Cc: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Basic call failed

Hi,

looks like your opensips will handle @40.0.0.164 as not local, so it will not 
ask your location db. Maybe you should entry the domain
40.0.0.164 in your domain table in mysql

BR

Uwe



XIN Xiuhe schrieb:
> Hi,  Please find attached logfile. thanks
> 
> -Original Message-
> From: Uwe Kastens [mailto:ki...@kiste.org]
> Sent: 2009年6月19日 14:33
> To: XIN Xiuhe
> Cc: users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] Basic call failed
> 
> Hi,
> 
> that looks ok. Could you please make a call with opensips at 
> debuglevel
> 9 at post the logfile?
> 
> BR
> 
> uwe
> 
> 
> 
> XIN Xiuhe schrieb:
>> mysql> select * from location;
>> ++--++--+--+--+-+---+-+--+-+---++-+-+-+
>> | id | username | domain | contact  | received | path | 
>> expires | q | callid  | cseq | last_modified 
>>   | flags | cflags | user_agent  | socket  | methods |
>> ++--++--+--+--+-+---+-+--+-+---++-+-+-+
>> | 11 | 0004 | NULL   | sip:0...@40.0.0.165:5060 | NULL | NULL | 
>> 2009-06-19 13:41:26 | -1.00 | 1569339300-27981165 |2 | 2009-06-19 
>> 12:41:26 | 0 |  0 | Alcatel-Lucent ISAM | udp:40.0.0.164:7060 |
>> 3199 | 
>> | 12 | 0003 | NULL   | sip:0...@40.0.0.165:5060 | NULL | NULL | 
>> 2009-06-19 13:41:28 | -1.00 | 1570548700-27981169 |2 | 2009-06-19 
>> 12:41:28 | 0 |  0 | Alcatel-Lucent ISAM | udp:40.0.0.164:7060 |
>> 3199 | 
>> ++--++--+--+--+-+---+-+--+-+---++-+-+-+
>> 2 rows in set (0.00 sec)
>>
>> mysql> 
>>
>>
>> -Original Message-
>> From: Uwe Kastens [mailto:ki...@kiste.org]
>> Sent: 2009年6月19日 12:47
>> To: XIN Xiuhe
>> Cc: users@lists.opensips.org
>> Subject: Re: [OpenSIPS-Users] Basic call failed
>>
>> Hi,
>>
>> Are you working with a database? So what will the location table entries 
>> look like? eq select * from location where user="0004"
>>
>> BR
>>
>> Uwe
>>
>>
>> XIN Xiuhe schrieb:
>>> Hi, uwe
>>>
>>> Please find attached opensips.cfg.
>>>
>>> For this question: What will the contact from the location service show you 
>>> for Users? 
>>> I don't know what you mean, do you mean user A and B's contact info?
 user A: contact info is   0...@40.0.0.165,  uri is 0...@40.0.0.164
 user B: contact info is   0...@40.0.0.165 , uri is 0...@40.0.0.164
>>> Thanks for your help! 
>>>
>>> xxh
>>>
>>> -Original Message-
>>> From: Uwe Kastens [mailto:ki...@kiste.org]
>>> Sent: 2009年6月19日 12:15
>>> To: XIN Xiuhe
>>> Cc: users@lists.opensips.org
>>> Subject: Re: [OpenSIPS-Users] Basic call failed
>>>
>>> Hi,
>>>
>>> What will the contact from the location service show you for Users?
>>> Could you post your opensips.cfg?
>>>
>>> BR
>>>
>>> Uwe
>>>
>>> XIN Xiuhe schrieb:
 Hi,

 I tried to use opensips to make a basic call, but failed.

 user A:  0...@40.0.0.165
 user B:  0...@40.0.0.165
 Both of them registered with opensips(ip address: 40.0.0.164) 
 successfully.

 User A off hook and call user B, after opensips received the invite 
 message, it should send it to 40.0.0.165, but from the trace 
 (attached "basiccall.pcap"), it send it to 40.0.0.164.

 What is the root cause, can somebody give some ideas?

 Thanks ! 






 ---
 -
 -
 -
 --

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


-- 

kiste lat: 54.322684, lon: 10.13586

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

Re: [OpenSIPS-Users] Load balancer module

[Bogdan-Andrei Iancu]

Hi Josip,

could you print the $du variable after you successfully do load_balance() ?

like add :
xlog(" new destination is %du \n");

and see if the printed URI does contain the port part also ?

Regards,
Bogdan

Josip Djuricic wrote:
> Hi,
>
> Since we are at load_balancer module I've noticed one strange behaviour on
> trunk and 1.5.0 version also.
>
> I see that every request is sent to port 5060 no matter what I've put in
> dst_uri field...i.e. if I put sip:xxx.xxx.xxx.xxx:port_number, it will still
> send everything to port 5060 instead of defined port_number, ofcourse
> looping itself if opensips is on port 5060 on the same ip.
>
> I've tried this with the example from the web, so perhaps I am doing
> something wrong?
>
> Best regards,
>
> Josip
>
>
>
>
> -Original Message-
> From: users-boun...@lists.opensips.org
> [mailto:users-boun...@lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
> Sent: Friday, June 19, 2009 9:12 AM
> To: Brett Nemeroff
> Cc: users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] Load balancer module
>
> HI Brett,
>
> Brett Nemeroff wrote:
>   
>> All,
>> What's the actual status of the load balancer module? I see in 1.5 
>> it's alpha/NEW. Is it usable yet?
>> 
> alpha means in not 100% tested (but does not mean is not stable). Also 
> it means that devel is still on progress as I plan to add some more 
> features on it/
>   
>> I don't know how conservative those labels are.
>> 
> as much as possible :)
>
> Regards,
> Bogdan
>   
>> -Brett
>>
>> 
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>   
>> 
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>   


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

Re: [OpenSIPS-Users] update location table on REGISTER request

[Jayesh Nambiar]

Thank you Bogdan, for the correct approach explained.But the append branch
then applies to all users right? What i was trying to do here was:
1) Allow some basic users to have only one registration contact possible.
2) Allow premium users to have as many contacts possible and receive calls
on any of the location.

Based upon certain conditions can i increase the append branch parameter
after looking up location and before relaying !!!
Just a thought.

--- Jay

On Fri, Jun 19, 2009 at 12:38 PM, Bogdan-Andrei Iancu <
bog...@voice-system.ro> wrote:

> HI Jayesh,
>
> What you could do is to accept 2-3 registrations, but to actually use the
> last one only.
>
> So set the mac_contacts to 2 or 3, the append_branches to 0 (to use only
> one contact) and in usrloc module set desc_time_order to 1 (
> http://www.opensips.org/html/docs/modules/1.5.x/usrloc.html#id266565) to
> sort contacts based on the registration time (first used will be the last
> registered)
>
> Regards,
> Bogdan
>
> Jayesh Nambiar wrote:
>
>> Hi All,
>> I had a requirement of allowing only one registration per user in a
>> particular scenario. I did not want to use the max_contacts parameter of
>> registrar module as it wont work right !!! The drawback was:
>> If device A had registered successfully and for some reason got
>> disconnected from the internet, the device won't unregister itself. Opensips
>> still has the record in the location table for that device, now if the
>> internet comes back and when the device tries to register again, opensips
>> will not allow since it already has the record in the location.
>> The device will have to wait until the earlier registration expires in the
>> opensips.
>> The idea was to have a way of updating the location table if same user is
>> trying to REGISTER from same location or different location. Meaning if user
>> A is registered from location A and someone else using same credentials of
>> user A tries to register from location B, the location table should only
>> update the earlier record to location B and not keep location A and location
>> B both for user A.
>>
>> Is there a way to do this. Any help will be highly appreciiated.
>>
>> Thanks in advance.
>>
>> --- Jay
>> 
>>
>> ___
>> 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] LDAP Authentication

[Bogdan-Andrei Iancu]

Alan,

Could you post the part of the script taking care of the REGISTRATION 
part, just for double checking ?

Also, for the password...does not look ok - not sure how that value is 
computed, but please check the Digest Auth RFC to see the definition of 
HA1 .

Regards,
Bogdan



Alan Rubin wrote:
> (reposting to fit the list size limits)
>
> Bogdan,
>
> 2) I removed the "!" from the REGISTER section.  This seems to have at
> least pushed me on to the next stage of actually doing an LDAP query:
>
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:ldap:ldap_url_search: LDAP URL parsed into session_name
> [sipaccounts], base [o=ntg], scope [2], filter
> [(&(cn=oh5)(departmentNumber=66)(ntguserstatus=Active))]
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:ldap:lds_search: [sipaccounts]: performing LDAP search: dn [o=ntg],
> scope [2], filter
> [(&(cn=oh5)(departmentNumber=66)(ntguserstatus=Active))], client_timeout
> [500] usecs
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:ldap:ldap_params_search: [sipaccounts]: [1] LDAP entries found
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:auth:check_nonce: comparing
> [4a3ae9d1b43a57f1ad95192b98ace5030eb50d1a] and
> [4a3ae9d1b43a57f1ad95192b98ace5030eb50d1a]
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:auth:reserve_nonce_index: second= 12, sec_monit= -1,  index= 2
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:auth:build_auth_hf: nonce index= 2
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:auth:build_auth_hf: 'Proxy-Authenticate: Digest
> realm="155.205.69.126",
> nonce="4a3ae9d2c65c88df6909b9e945bdbaaa5e495b3a"  '
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:core:parse_headers: flags=
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:core:check_via_address: params 155.205.26.124, 155.205.26.124, 0
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:core:destroy_avp_list: destroying list (nil)
> Jun 19 10:58:18 dcshub1 /usr/local/opensips/sbin/opensips[31159]:
> DBG:core:receive_msg: cleaning up
> ...
>
> Still failing, but this time it is code 407: Proxy Authentication
> Required.  Getting closer?
>
> 1) Perhaps I mean "encoded" and am just using the wrong term.  An
> example return from our LDAP search:
>  userPassword: {SSHA}twmolvRuvt11fr4GVJOxIasfcGi6yci9LIEfaUQ==
>
> Regards,
>
> Alan Rubin
>  
> -Original Message-
> From: Bogdan-Andrei Iancu [mailto:bog...@voice-system.ro] 
> Sent: Friday, 19 June 2009 10:52 AM
> To: Alan Rubin
> Cc: users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] LDAP Authentication
>
> Alan,
>
> 2 points:
>
> 1) what you mean by "encrypted" ? the module supports only ha1 encoded 
> passwords.
>
> 2) I see you deal with a REGISTER request, but in your script you 
> changed the auth (from DB to LDAP) only for INVITES - check in the 
> script the second auth block (for REGISTERS) and change it in the same 
> time as we did for the INVITEs.
>
> Regards,
> Bogdan
>
> Alan Rubin wrote:
>   
>> Bogdan,
>>
>> Thanks for your help.  I reset the configuration for calculate_ha1 to
>> 
> 0
>   
>> (it was set to 1), but I am still getting a "401 - Unauthorized"
>> 
> error.
>   
>> The password returning from the LDAP server should be an encrypted
>> string.
>>
>> # - auth_db params -
>> /* uncomment the following lines if you want to enable the DB based
>>authentication */
>> #modparam("auth_db", "calculate_ha1", yes)
>> #modparam("auth_db", "password_column", "password")
>> #modparam("auth_db", "db_url",
>> #   "mysql://opensips:@localhost/opensips")
>> #modparam("auth_db", "load_credentials", "")
>>
>> # -- auth params -
>> #modparam("auth", "username_spec", "$var(username)")
>> #modparam("auth", "password_spec", "$avp(s:password)")
>> modparam("auth", "nonce_expire",  30)
>> modparam("auth", "secret", "")
>> modparam("auth", "disable_nonce_check", 0)
>> modparam("auth", "username_spec", "$var(username)")
>> modparam("auth", "password_spec", "$avp(s:password)")
>> modparam("auth", "calculate_ha1", 0)
>>
>> Here are the relevant logs from the connection (I think):
>>
>>
>> 


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

Re: [OpenSIPS-Users] Basic call failed

[Uwe Kastens]

Hi,

looks like your opensips will handle @40.0.0.164 as not local, so it
will not ask your location db. Maybe you should entry the domain
40.0.0.164 in your domain table in mysql

BR

Uwe



XIN Xiuhe schrieb:
> Hi,  Please find attached logfile. thanks 
> 
> -Original Message-
> From: Uwe Kastens [mailto:ki...@kiste.org] 
> Sent: 2009年6月19日 14:33
> To: XIN Xiuhe
> Cc: users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] Basic call failed
> 
> Hi,
> 
> that looks ok. Could you please make a call with opensips at debuglevel
> 9 at post the logfile?
> 
> BR
> 
> uwe
> 
> 
> 
> XIN Xiuhe schrieb:
>> mysql> select * from location;
>> ++--++--+--+--+-+---+-+--+-+---++-+-+-+
>> | id | username | domain | contact  | received | path | 
>> expires | q | callid  | cseq | last_modified 
>>   | flags | cflags | user_agent  | socket  | methods |
>> ++--++--+--+--+-+---+-+--+-+---++-+-+-+
>> | 11 | 0004 | NULL   | sip:0...@40.0.0.165:5060 | NULL | NULL | 
>> 2009-06-19 13:41:26 | -1.00 | 1569339300-27981165 |2 | 2009-06-19 
>> 12:41:26 | 0 |  0 | Alcatel-Lucent ISAM | udp:40.0.0.164:7060 |
>> 3199 | 
>> | 12 | 0003 | NULL   | sip:0...@40.0.0.165:5060 | NULL | NULL | 
>> 2009-06-19 13:41:28 | -1.00 | 1570548700-27981169 |2 | 2009-06-19 
>> 12:41:28 | 0 |  0 | Alcatel-Lucent ISAM | udp:40.0.0.164:7060 |
>> 3199 | 
>> ++--++--+--+--+-+---+-+--+-+---++-+-+-+
>> 2 rows in set (0.00 sec)
>>
>> mysql> 
>>
>>
>> -Original Message-
>> From: Uwe Kastens [mailto:ki...@kiste.org]
>> Sent: 2009年6月19日 12:47
>> To: XIN Xiuhe
>> Cc: users@lists.opensips.org
>> Subject: Re: [OpenSIPS-Users] Basic call failed
>>
>> Hi,
>>
>> Are you working with a database? So what will the location table entries 
>> look like? eq select * from location where user="0004"
>>
>> BR
>>
>> Uwe
>>
>>
>> XIN Xiuhe schrieb:
>>> Hi, uwe
>>>
>>> Please find attached opensips.cfg.
>>>
>>> For this question: What will the contact from the location service show you 
>>> for Users? 
>>> I don't know what you mean, do you mean user A and B's contact info?
 user A: contact info is   0...@40.0.0.165,  uri is 0...@40.0.0.164
 user B: contact info is   0...@40.0.0.165 , uri is 0...@40.0.0.164
>>> Thanks for your help! 
>>>
>>> xxh
>>>
>>> -Original Message-
>>> From: Uwe Kastens [mailto:ki...@kiste.org]
>>> Sent: 2009年6月19日 12:15
>>> To: XIN Xiuhe
>>> Cc: users@lists.opensips.org
>>> Subject: Re: [OpenSIPS-Users] Basic call failed
>>>
>>> Hi,
>>>
>>> What will the contact from the location service show you for Users?
>>> Could you post your opensips.cfg?
>>>
>>> BR
>>>
>>> Uwe
>>>
>>> XIN Xiuhe schrieb:
 Hi,

 I tried to use opensips to make a basic call, but failed.

 user A:  0...@40.0.0.165
 user B:  0...@40.0.0.165
 Both of them registered with opensips(ip address: 40.0.0.164) 
 successfully.

 User A off hook and call user B, after opensips received the invite 
 message, it should send it to 40.0.0.165, but from the trace 
 (attached "basiccall.pcap"), it send it to 40.0.0.164.

 What is the root cause, can somebody give some ideas?

 Thanks ! 






 
 -
 -
 --

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


-- 

kiste lat: 54.322684, lon: 10.13586

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

Re: [OpenSIPS-Users] Load balancer sending 403 when caller hangs uo

[Bogdan-Andrei Iancu]

Hi James,

Could you please check if the "dialog" module sees the call as ended? Use 
"opensipsctl fifo dlg_list"  
(http://www.opensips.org/html/docs/modules/1.5.x/dialog.html#id272726) 
and paste the output here.

Also, do you have a full SIP trace of the call (ngrep) ?

Regards,
Bogdan



James Wiegand wrote:
> Hi all,
>
> I am using OpenSIPS 1.5.1 and the lb module.  Following the example I
> see this chunk of code execute when the caller hangs up as the dial
> progresses (but before the other side answers):
>
> # from now on we have only the initial requests
> if (!is_method("INVITE")) {
> send_reply("405","Method Not Allowed");
> exit;
> }
>
> This leaves a session hanging in the load balancer:
>
> Destination:: sip:XXX.XXX.XXX.XXX id=3
> Resource:: pstn max=1 load=1
>
> I'm seeing CANCEL come in from the caller and it looks like
> !t_check_trans() is not picking this up?  How do I catch this case?
>
> Thanks for the help,
>
> -jim
>
>
>   


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

Re: [OpenSIPS-Users] Load balancer module

[Josip Djuricic]

Hi,

Since we are at load_balancer module I've noticed one strange behaviour on
trunk and 1.5.0 version also.

I see that every request is sent to port 5060 no matter what I've put in
dst_uri field...i.e. if I put sip:xxx.xxx.xxx.xxx:port_number, it will still
send everything to port 5060 instead of defined port_number, ofcourse
looping itself if opensips is on port 5060 on the same ip.

I've tried this with the example from the web, so perhaps I am doing
something wrong?

Best regards,

Josip




-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
Sent: Friday, June 19, 2009 9:12 AM
To: Brett Nemeroff
Cc: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Load balancer module

HI Brett,

Brett Nemeroff wrote:
> All,
> What's the actual status of the load balancer module? I see in 1.5 
> it's alpha/NEW. Is it usable yet?
alpha means in not 100% tested (but does not mean is not stable). Also 
it means that devel is still on progress as I plan to add some more 
features on it/
> I don't know how conservative those labels are.
as much as possible :)

Regards,
Bogdan
> -Brett
>
> 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


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


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

Re: [OpenSIPS-Users] Load balancer module

[Bogdan-Andrei Iancu]

HI Brett,

Brett Nemeroff wrote:
> All,
> What's the actual status of the load balancer module? I see in 1.5 
> it's alpha/NEW. Is it usable yet?
alpha means in not 100% tested (but does not mean is not stable). Also 
it means that devel is still on progress as I plan to add some more 
features on it/
> I don't know how conservative those labels are.
as much as possible :)

Regards,
Bogdan
> -Brett
>
> 
>
> ___
> 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] update location table on REGISTER request

[Bogdan-Andrei Iancu]

HI Jayesh,

What you could do is to accept 2-3 registrations, but to actually use 
the last one only.

So set the mac_contacts to 2 or 3, the append_branches to 0 (to use only 
one contact) and in usrloc module set desc_time_order to 1 
(http://www.opensips.org/html/docs/modules/1.5.x/usrloc.html#id266565) 
to sort contacts based on the registration time (first used will be the 
last registered)

Regards,
Bogdan

Jayesh Nambiar wrote:
> Hi All,
> I had a requirement of allowing only one registration per user in a 
> particular scenario. I did not want to use the max_contacts parameter 
> of registrar module as it wont work right !!! The drawback was:
> If device A had registered successfully and for some reason got 
> disconnected from the internet, the device won't unregister itself. 
> Opensips still has the record in the location table for that device, 
> now if the internet comes back and when the device tries to register 
> again, opensips will not allow since it already has the record in the 
> location.
> The device will have to wait until the earlier registration expires in 
> the opensips.
> The idea was to have a way of updating the location table if same user 
> is trying to REGISTER from same location or different location. 
> Meaning if user A is registered from location A and someone else using 
> same credentials of user A tries to register from location B, the 
> location table should only update the earlier record to location B and 
> not keep location A and location B both for user A.
>
> Is there a way to do this. Any help will be highly appreciiated.
>
> Thanks in advance.
>
> --- Jay
> 
>
> ___
> 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] opensips crash - mysql

[Bogdan-Andrei Iancu]

Hi Jayesh, Hi Brett,

I sent the patch couple of days ago - see  
http://lists.opensips.org/pipermail/users/2009-June/005986.html

I will be great if you could apply the patch and get some logs around 
the original error.

Thanks and regards,
Bogdan

Jayesh Nambiar wrote:
> Hi Brett,
> This is a similar error that I had got in my environment too. In my 
> case it used to get sorted out after restarting my MySQL and Opensips. 
> But used to occur again after say 10-15 days.
> Unfortunately I did not take the core dump. I had asked Bogdan if 
> prepared statements can be disabled for particular modules and he said 
> he will prepare a patch or make it configurable in the config.h file.
>
> --- Jayesh
>  
>
>
> Message: 2
> Date: Wed, 17 Jun 2009 01:55:29 -0500
> From: Brett Nemeroff mailto:br...@nemeroff.com>>
> Subject: [OpenSIPS-Users] opensips crash - mysql
> To: users@lists.opensips.org 
> Message-ID:
>  
>  <4f67656a0906162355p4f6ec50fk5bf51b4979ebc...@mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> All,
> I ran into an interesting crash in my test env today.
>
> I took a very large acc table and reindexed it with a complicated
> index..
> while this was going on I placed calls and got the following errors:
> Jun 17 01:47:40 voicefox-dev /usr/local/sbin/opensips[25170]:
> ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_bind_param()
> failed:
> Using unsupported buffer type: 744972660  (parameter: 14)
> Jun 17 01:47:40 voicefox-dev /usr/local/sbin/opensips[25170]:
> ERROR:siptrace:trace_sl_onreply_out: error storing trace
>
> and then opensips segfaulted.
>
> here's the bt:
> Core was generated by `/usr/local/sbin/opensips -P
> /var/run/opensips.pid -m
> 2048'.
> Program terminated with signal 11, Segmentation fault.
> [New process 25156]
> #0  0x0034c1a7b733 in memcpy () from /lib64/libc.so.6
> (gdb) bt
> #0  0x0034c1a7b733 in memcpy () from /lib64/libc.so.6
> #1  0x003c28a25a49 in mysql_stmt_bind_param () from
> /usr/lib64/mysql/libmysqlclient.so.15
> #2  0x2b621bb194de in db_mysql_do_prepared_query (conn=0x79a5f8,
> query=0x2b621bd31730, v=0x7fff8efa1890, n=10, uv=0x0, un=0) at
> dbase.c:497
> #3  0x2b621bb1b7c4 in db_mysql_insert (_h=0x79a5f8,
> _k=0x7fff8efa19d0,
> _v=0x7fff8efa1890, _n=10) at dbase.c:929
> #4  0x2b621da6ee96 in sip_trace (msg=0x79d3d0) at siptrace.c:629
> #5  0x2b621da70740 in trace_dialog (msg=0x79d3d0) at
> siptrace.c:461
> #6  0x0040dcfc in do_action (a=0x77e3c8, msg=0x79d3d0) at
> action.c:962
> #7  0x0041079e in run_action_list (a=,
> msg=0x79d3d0) at action.c:139
> #8  0x0040eb40 in do_action (a=0x77e498, msg=0x79d3d0) at
> action.c:706
> #9  0x0041079e in run_action_list (a=,
> msg=0x79d3d0) at action.c:139
> #10 0x0040eb40 in do_action (a=0x7833e8, msg=0x79d3d0) at
> action.c:706
> #11 0x0041079e in run_action_list (a=,
> msg=0x79d3d0) at action.c:139
> #12 0x00410af9 in run_top_route (a=0x770778, msg=0x79d3d0) at
> action.c:119
> #13 0x0044f3df in receive_msg (
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> 
> http://lists.opensips.org/pipermail/users/attachments/20090617/0fdc655c/attachment-0001.htm
>
> 
>
> ___
> 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