[OpenSIPS-Users] SIP trace and OpenSIPS-CP 2.0

Bogdan-Andrei Iancu bogdan at voice-system.ro
Fri Oct 16 02:57:57 CEST 2009


Hi Marc,

Do not use random values :) - the flag you configure must also be used:

#------ siptrace db url ----
modparam("siptrace", "db_url","mysql://root:abc123@localhost/opensips")
modparam("siptrace", "trace_flag", 22)

####### Routing Logic ########


# main request routing logic

route{

	setfalg(22);
        sip_trace();
.
.
.

}

regards,
bogdan


marcher wrote:
> Hi Bogdan,
>
> I tried values of both 22 (as per the link you sent) and 13 (from google
> search results) both still only see incoming requests. No outgoing requests
> or reponses.
>
> #------ siptrace db url ----
> modparam("siptrace", "db_url","mysql://root:abc123@localhost/opensips")
> modparam("siptrace", "trace_flag", 22)
>
> ####### Routing Logic ########
>
>
> # main request routing logic
>
> route{
>
>         sip_trace();
> .
> .
> .
>
> Is there a description anywhere as to what the value of the flag mean?
>
> Any ideas?
>
> Cheers,
>
> Marc
>
>
>
> Bogdan-Andrei Iancu wrote:
>   
>> Hi Marc,
>>
>> sip_trace() traces only the current request - that's it; to trace the 
>> whole transaction (the replies also), you need to set the tracing flag 
>> (http://www.opensips.org/html/docs/modules/1.5.x/siptrace.html#id227228) 
>> also:
>>     seflag(NN);
>>     sip_trace();
>>
>> Regards,
>> Bogdan
>>
>> marcher wrote:
>>     
>>> Hi Bogdan,
>>>
>>> Again, thanks for the help.
>>>
>>> I want to capture all ingress and egress traffic for now. So I put
>>> sip_trace(); at the very start of the main request routing logic. This
>>> worked great for incoming methods REGISTER, INVITE, OPTIONS, ACK and BYE.
>>>
>>> When tracing is enabled via opensips-cp I see the methods, and can click
>>> on
>>> Call to expand to see all the messages.
>>>
>>> However, I don't see any egress messages, either outgoing requests or
>>> 1xx,
>>> 2xx, 4xx responses from opensips in the opensips-cp table.
>>>
>>> I tried adding sip_trace() to opensips.cfg as follows but no dice. I
>>> guess I
>>> didn't understand what your suggestion "just before sending the request
>>> out"
>>> actually means in terms of opensips.cfg
>>>
>>> route[1] {
>>>
>>>         # for INVITEs enable some additional helper routes
>>>         if (is_method("INVITE")) {
>>>                 t_on_branch("2");
>>>                 t_on_reply("2");
>>>                 t_on_failure("1");
>>>         }
>>>
>>>
>>>         sip_trace();
>>>
>>>         if (!t_relay()) {
>>>                 sl_reply_error();
>>>         };
>>>         exit;
>>> }
>>>
>>> I completely understand about not having a standard config that covers
>>> all
>>> the possibilities opensips-cp can control.
>>>
>>> I do wish to use drouting such that I can conveniently add new phone
>>> number
>>> prefixes and have them route to gateways via opensips-cp. But I also wish
>>> this functionality to work with calls to endpoints directly registered
>>> with
>>> opensips.
>>>
>>> If I add the do_routing logic before the usrloc lookup logic, I get a 503
>>> for a call to a valid registered endpoint.
>>>
>>>         xlog("-----Doing routing\n");
>>>
>>>         if (!do_routing("1")) {
>>>                 sl_send_reply("503","No destination available");
>>>                 exit;
>>>         }
>>>
>>>         xlog("-----gw attr is $avp(s:dr_attrs)\n");
>>>         xlog("-----ruri is $ru\n");
>>>
>>>         if (!lookup("location")) {
>>>                 switch ($retcode) {
>>>                         case -1:
>>>                         case -3:
>>>                                 t_newtran();
>>>                                 t_reply("404", "Not Found");
>>>                                 exit;
>>>                         case -2:
>>>                                 sl_send_reply("405", "Method Not
>>> Allowed");
>>>                                 exit;
>>>                 }
>>>         }
>>>
>>>         # when routing via usrloc, log the missed calls also
>>>         setflag(2);
>>>
>>>         route(1);
>>>
>>>
>>> If I add the do_routing logic after the usrloc lookup logic, I get a 404
>>> from case -3 for a call destined for a gateway.
>>>
>>> How can I setup my opensips.cfg such that calls to registered endpoints
>>> and
>>> calls to gateway hosted numbers work in conjunction?
>>>
>>> Cheers,
>>>
>>> Marc
>>>
>>>
>>> Bogdan-Andrei Iancu wrote:
>>>   
>>>       
>>>> Hi Marc,
>>>>
>>>>
>>>> marcher wrote:
>>>>     
>>>>         
>>>>> Hi Bogdan,
>>>>>
>>>>> I appreciate you taking the time to answer my basic questions in
>>>>> getting
>>>>> opensips-cp functional with my opensips implementation.
>>>>>
>>>>> I had read the link you included, but its still not clear to me where
>>>>> the
>>>>> sip_trace function should be called within the opensips config file.
>>>>>   
>>>>>       
>>>>>           
>>>> there is not special place for it - you need to call the sip_trance() 
>>>> and set the trace flag when you process the SIP requests - you can do 
>>>> this in the very beginning of the script or just before sending the 
>>>> request out - it is up to you and up to what kind of traffic you want to 
>>>> trace.
>>>>
>>>> For example, if you want to trace only calls to your local subscribers, 
>>>> you can add the sip_trace() in the if (ruri==myself) {} block.
>>>>     
>>>>         
>>>>> My opensips config file is very straightforward, based heavily on the
>>>>> distribution sample, but adding piecemeal the config necessary to
>>>>> integrate
>>>>> opensips-cp (mi_xmlrpc, dialplan, drouting and siptrace modules to
>>>>> date)
>>>>> I
>>>>> also wish to add in SIP trunking gateways using drouting.
>>>>>   
>>>>>       
>>>>>           
>>>> you do not need to put in the opensips script all the functionalities 
>>>> required by opensips-cp. You can select in opensips-cp only the tools 
>>>> you find useful in your opensips script. If you do not need drouting in 
>>>> opensips cfg, simply remove the drouting tool from CP.
>>>>     
>>>>         
>>>>> To that end, I am also struggling with the correct opensips config to
>>>>> implement drouting such that it works in tandem with the
>>>>> lookup(location)
>>>>> functionality.
>>>>>   
>>>>>       
>>>>>           
>>>> Could you describe a bit more the logic you want here?
>>>>     
>>>>         
>>>>> Does there exist a sample config that I could work from that would
>>>>> achieve
>>>>> these goals? I'm surprised the folks that produced opensips-cp didn't
>>>>> post
>>>>> an opensips config file that would successfully work in tandem with
>>>>> their
>>>>> GUI.
>>>>>   
>>>>>       
>>>>>           
>>>> because this is impossible :)...opensips-cp allows you to provision some 
>>>> functionality blocks (like dialplan, drouting, nathelper, permissions, 
>>>> etc). In your opensips cfg you can combine in millions of ways these 
>>>> block to get different overall routing logic.
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>>     
>>>>         
>>>>> Thanks again.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Marc
>>>>>
>>>>>
>>>>> Bogdan-Andrei Iancu wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Hi Marc,
>>>>>>
>>>>>> loading the siptrace module is not enough. You need to use the 
>>>>>> sip_trace() function and set the trace_flag (for transaction tracing).
>>>>>> See:
>>>>>>    
>>>>>> http://www.opensips.org/html/docs/modules/1.5.x/siptrace.html#id228291
>>>>>>
>>>>>> Best regards,
>>>>>> Bogdan
>>>>>>
>>>>>> marcher wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> Hi,
>>>>>>>
>>>>>>> Trying to get sip trace functionality on opensips-cp working also. 
>>>>>>>
>>>>>>> Toggling the trace on and off from the web interface appears to be
>>>>>>> working
>>>>>>> fine.
>>>>>>>
>>>>>>> Oct  7 13:08:59 [2332] DBG:mi_xmlrpc:default_method: starting up.....
>>>>>>> Oct  7 13:08:59 [2332] DBG:mi_xmlrpc:default_method: done looking the
>>>>>>> mi
>>>>>>> command.
>>>>>>> Oct  7 13:08:59 [2332] DBG:mi_xmlrpc:default_method: done parsing the
>>>>>>> mi
>>>>>>> tree.
>>>>>>> Oct  7 13:08:59 [2332] DBG:mi_xmlrpc:default_method: done running the
>>>>>>> mi
>>>>>>> command.
>>>>>>> Oct  7 13:08:59 [2332] DBG:mi_xmlrpc:default_method: done building
>>>>>>> response.
>>>>>>>
>>>>>>> However, nothing gets written to the mysql db siptrace table. 
>>>>>>>
>>>>>>> Hence, nothing gets written to the siptrace table on opensip-cp.
>>>>>>>
>>>>>>> I'm testing it with SJPhone registering to opensips from the same
>>>>>>> local
>>>>>>> machine.
>>>>>>>
>>>>>>> I added the following parameters to opensips.cfg
>>>>>>>
>>>>>>> loadmodule "siptrace.so"
>>>>>>>
>>>>>>> #------ siptrace db url ----
>>>>>>> modparam("siptrace",
>>>>>>> "db_url","mysql://root:######@localhost/opensips")
>>>>>>>
>>>>>>> Is this the correct format for the siptrace db_url? 
>>>>>>>
>>>>>>> The only thing I see in the log that looks related is:
>>>>>>>
>>>>>>> Oct  7 13:02:53 [2324] DBG:siptrace:trace_sl_onreply_out: trace
>>>>>>> off...
>>>>>>>
>>>>>>> For the drouting module, I have the db_url configured as 
>>>>>>>
>>>>>>> modparam("drouting",
>>>>>>> "db_url","mysql://opensips:opensipsrw@localhost/opensips")
>>>>>>>
>>>>>>> I did try changing the siptrace db_url to this format, but it didn't
>>>>>>> work
>>>>>>> either.
>>>>>>>
>>>>>>> Any help greatly appreciated.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Marc
>>>>>>>
>>>>>>>
>>>>>>> Iulia Bublea-2 wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> Load the siptrace module in the opensips.cfg and set the db
>>>>>>>> parameter.
>>>>>>>>
>>>>>>>> Iulia
>>>>>>>>
>>>>>>>> Gavin Henry wrote:
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> Quick one,
>>>>>>>>>
>>>>>>>>> I presume you need the sip_trace function in the right place and
>>>>>>>>> that
>>>>>>>>> you just toggle it on/off via the cp?
>>>>>>>>>
>>>>>>>>> Also, you will need the db_url if logging to mysql?
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>   
>>>>>>>>>
>>>>>>>>>               
>>>>>>>>>                   
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>     
>
>   




More information about the Users mailing list