Re: Problem using OpenSIPS with SIPp for testing

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Problem using OpenSIPS with SIPp for testing

mayamatakeshi
On Sat, Mar 14, 2009 at 2:49 PM, SAMEER KUMAR <[hidden email]> wrote:
> Hi Takeshi,
>
> I used the exact cfg file you sent. But that too seems to be not helping me.

Sameer,
the cfg does work. I tested using an eyebeam phone. The call goes thru
opensips and it is relayed to another terminal.

> I debugged to find out that the message processing does not go to the
> if(method="INVITE" conditional branch.

If the processing of the request doesn't reach that line, then maybe
the message received (generated by SIPp), is not properly formed. Have
you checked the contents of the message?
Also, have you tried to call using some UA like x-lite?
Put some xlog in the cfg and check where and why the above line is not
hit by the processing.

> I then added all the t_relay and
> other functions in the route[1] branch (anyways relaying would be needed for
> ACKs revieved as well). But that too does not seem to be working. I found
> the t_relay returns following error in route[1].
>
>
> Mar 14 16:58:54 [3891] ERROR:tm:t_forward_nonack: no branch for forwarding
> Mar 14 16:58:54 [3891] ERROR:tm:w_t_relay: t_forward_nonack failed
> Mar 14 16:59:24 [3892] CRITICAL:tm:t_should_relay_response: pick_branch
> failed (lowest==-1) for code 408
>
>
> I am not getting where the things are goinf wrong...
>
> Can you please throw some light.
>
> Sameer Kumar
> B.Tech, Computer Engineering
> Institute of Technology,
> Nirma University,
> Ahmedabad, Gujarat
>
>
>
> On Fri, Mar 13, 2009 at 8:51 AM, mayamatakeshi <[hidden email]>
> wrote:
>>
>> On Fri, Mar 13, 2009 at 9:04 PM, SAMEER KUMAR <[hidden email]>
>> wrote:
>> > Dear,
>> >
>> > Thanks for such a prompt reply.
>> >
>> > Earlier I was not even using a saperate processing for INVITE. I was
>> > supposed to be processed by the fefault call to route[1] (please refer
>> > to
>> > the cfg file). But as I noticed the problem I stated, I tought that the
>> > call
>> > to t_relay in route[1] is not being processed (in route[1] in the if
>> > condition check). So I made a explicit processing for INVITE and then
>> > used
>> >  t_relay. But when that too did not seemed to help I used stateless
>> > forward.
>> > I had tried lot many different things (like adding via and record route
>> > functions etc etc) and also tested other example cfg files. So be sure
>> > that
>> > there is no problem with cfg file. The problem persists ireespective of
>> > all
>> > that.
>>
>> Hello Sameer,
>> my current installation is not compiled with tls and I also don't have
>> the load_sig_api required by the registrar module. So I cleared your
>> cfg from registrar functions and running it I can see it does work
>> (i'm using opensips head  r. 5438). Here's the modified cfg file:
>>
>> debug=3
>> fork=no
>> log_stderror=yes
>> listen=192.168.2.3
>> port=5080
>> children=4
>> dns=yes
>> rev_dns=yes
>> #fifo= "/tmp/ser_fifo"
>>
>> mpath="/usr/local/lib/opensips/modules"
>>
>> loadmodule "sl.so"
>> loadmodule "tm.so"
>> loadmodule "rr.so"
>> loadmodule "maxfwd.so"
>> loadmodule "usrloc.so"
>>
>> modparam("usrloc", "db_mode", 0)
>> modparam("rr", "enable_full_lr", 1)
>> route  {
>>
>>   if (!mf_process_maxfwd_header("10")) {
>>      sl_send_reply("483", "Too Many Hops");
>>      return;
>>   };
>>
>>   if (msg:len > max_len) {
>>       sl_send_reply("513", "Message Overflow");
>>       return;
>>   };
>>
>>   if (method!="REGISTER") {
>>       record_route();
>>   };
>>
>>   if (loose_route()) {
>>       route(1);
>>       return;
>>   };
>>
>>   if (uri!=myself) {
>>       route(1);
>>       return;
>>   };
>>   if (method=="ACK") {
>>       route(1);
>>       return;
>>   }
>>
>>   if (method=="INVITE") {
>>
>>    add_local_rport();
>>    force_rport();
>>    forward();
>>    t_relay();
>>
>>    return;
>>   };
>>
>>   route(1);
>> }
>>
>> route[1] {
>>
>>   if (!t_relay()) {
>>       sl_reply_error();
>>   };
>>
>> }
>>
>> Maybe this is something related to TLS. Have you tried testing with no
>> TLS?
>
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users