[OpenSIPS-Users] Value of PATH is not being used in next_branches() in Faliure Route

Gomtesh Jain gomtesh at gmail.com
Tue Jun 12 13:04:44 CEST 2012


Hi Bogdan,
   I tried your fix , now it tries to next contact with proper destination
but the contact in that INVITE has some sysntax error .

<sip:855_1_7ag at 122.177.144.180:28056sip:855_1_7ag at 122.177.144.180:28056>

It appends the caller's contact 2 times .

Thanx,
Gomtesh

On Mon, Jun 11, 2012 at 8:13 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:

> **
> It seems the PATH value is properly processed by the next_branch()
> function - it is simply pushed into the message, but it is not used to
> extract the next destination.
>
> I made a small fix - see the attached patch - please apply it and let me
> know if it did the trick for you.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 06/11/2012 03:45 PM, Gomtesh Jain wrote:
>
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18488]:  ERROR
> RESPONSE MATCHED  method (INVITE) r-uri (<null>) :callID
> ZjUwZTkzMWI5ZjRjNDNjNDc1MGRhZDVmZjM3ZmY0YmQ. :CSeq 1
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
> DBG:core:parse_headers: via found, flags=22
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18488]:
> DBG:core:*next_branches*: Msg information <
> sip:855_1_7agentsURI at 122.177.144.180:2043;transport=TCP,sip:50.16.212.126:8060;lr
> ,<sip:50.16.212.126:8060;lr>,-1,0>
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
> DBG:core:parse_headers: parse_headers: this is the second via
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18488]:  ON
> FAILURE BLOCK  method (INVITE) r-uri (<null>) :callID
> ZjUwZTkzMWI5ZjRjNDNjNDc1MGRhZDVmZjM3ZmY0YmQ. :CSeq 1
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
> DBG:core:parse_to_param: tag=7963038936cb090485262a576bc5dd22-8eae
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18488]:
> DBG:core:check_ip_address: params 122.177.144.180, 192.168.3.128, 0
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
> DBG:core:parse_to: end of header reached, state=29
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18488]:
> DBG:core:parse_headers: flags=80
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
> DBG:core:parse_to: display={"855_1_7agentsURI"}, ruri={
> sip:855_1_7agentsURI at management.3clogic.com:5506}
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18488]:  IN
> ROUTE BLOCK method (INVITE) r-uri (<null>) :callID
> ZjUwZTkzMWI5ZjRjNDNjNDc1MGRhZDVmZjM3ZmY0YmQ.
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
> DBG:core:get_hdr_field: <To> [112]; uri=[
> sip:855_1_7agentsURI at management.3clogic.com:5506]
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18488]:
> DBG:core:mk_proxy: doing DNS lookup...
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
> DBG:core:get_hdr_field: to body ["855_1_7agentsURI"<
> sip:855_1_7agentsURI at management.3clogic.com:5506>]
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18488]:
> DBG:core:get_send_socket: force_send_socket of different proto (2)!
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
> DBG:core:get_hdr_field: cseq <CSeq>: <1> <INVITE>
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18488]:
> DBG:core:parse_headers: flags=2000
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
> DBG:core:parse_headers: flags=8
> Jun  8 11:40:03 ip-10-122-214-174 /usr/local/sbin/opensips[18488]:
> DBG:core:tcp_send: no open tcp connection found, opening new one
>
>
>  Thanx,
> Gomtesh
>
>
> On Mon, Jun 11, 2012 at 5:53 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:
>
>>  I see.....Seems ok.
>>
>> could you post the logs from next_branches() - it outputs similar logs
>> about the data pushed back into message.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>>   On 06/11/2012 03:07 PM, Gomtesh Jain wrote:
>>
>>
>>  Hi Bogdan,
>>       When I do serialize_branches(1) after look up , I can see both the
>> contacts in logs with proper PATH values (*50.16.212.126:8060*).
>> But It process 1st contact properly but after next_branches() it does not
>> process 2nd branch properly . It does not add *50.16.212.126:8060;lr *as
>> route.
>>
>>  Jun  8 11:39:55 ip-10-122-214-174 /usr/local/sbin/opensips[18491]:
>> DBG:core:*serialize_branches: Msg information <
>> sip:855_1_7agentsURI at 115.252.66.182:3912;transport=TCP,sip:50.16.212.126:8060;lr
>> ,<sip:50.16.212.126:8060;lr>,-1,0>*
>> Jun  8 11:39:55 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
>> DBG:core:parse_headers: via found, flags=2
>> Jun  8 11:39:55 ip-10-122-214-174 /usr/local/sbin/opensips[18491]:
>> DBG:core:*serialize_branches: Branch information <
>> sip:855_1_7agentsURI at 122.177.144.180:2043;transport=TCP,sip:50.16.212.126:8060;lr
>> ,<sip:50.16.212.126:8060;lr>,-1,0>*
>> Jun  8 11:39:55 ip-10-122-214-174 /usr/local/sbin/opensips[18490]:
>> DBG:core:parse_headers: this is the first via
>>
>>
>>  Thanx,
>> Gomtesh
>>
>> On Mon, Jun 11, 2012 at 3:34 PM, Bogdan-Andrei Iancu <bogdan at opensips.org
>> > wrote:
>>
>>>  Hi Gomtesh,
>>>
>>> Do your saved contacts contain a PATH field at all ? check with
>>> "opensipsctl ul show" to see if the path was stored in usrloc cache.
>>>
>>> Maybe your problem is not at "lookup" time, but rather at "save" time.
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>>
>>> On 06/11/2012 10:56 AM, Gomtesh Jain wrote:
>>>
>>>  Hi ,
>>>    I am using opensips 1.6 . I am facing an issue here . It seems In
>>> faliure route when I do next_branches() it does not set value of "path"
>>> (from lookup) as distination/route . Which results , opensips try to send
>>> message directly to UA .
>>>
>>> Here I give N/w diagram
>>>
>>>    UA1(115.X.X.X)-------[PROXY]--------|
>>>     |
>>>                                                           |
>>> Registrar/Opensips   |
>>>   UA2 (122.x.x.x)--------[PROXY]-------|
>>>   |
>>>
>>>
>>>  The issue I am facing is ...
>>> 1. On any INVITE to Opensips after lookup Opensips sends invite to Proxy
>>> 2. On any faliure response in "Faiure Route"
>>> 3. When I do next_branches() it tries to send INVITE directly to
>>> 122.X.X.X .
>>>
>>>  -----------------HERE I GIVE PIECE OF Opnesips.cfg--------------------
>>>
>>>
>>>         xlog("L_NOTICE", "SERIALIZE BRANCHES ($rm) r-uri ($ru) :
>>> Contact : $ct  :callID $ci : CSeq $cs \n");
>>>                         if (!serialize_branches(1)){
>>>                                 sl_send_reply("500","Unable to load
>>> contacts");
>>>                                 exit;
>>>                         }else{
>>>                       xlog("L_NOTICE", "PREPARE FIRST BRANCH ($rm) r-uri
>>> ($ru) : Contact : $ct  :callID $ci : CSeq $cs \n");
>>>                                 if (next_branches()){
>>>                                     xlog("L_NOTICE", "NEXT BRANCH After
>>> Seri :callID $ci : CSeq $cs \n");
>>>                                         t_on_failure("1");
>>>                                 }
>>>                                 #else{
>>>                                 #       sl_send_reply("504","Not found
>>> ");
>>>                                 #       exit;
>>>                                 #}
>>>                         }
>>>                         append_hf("P-hint: lcr applied\r\n");
>>>
>>>                  }else{
>>>                         append_hf("P-hint: usrloc applied\r\n");
>>>                 }
>>>
>>>          };
>>>
>>>          route(1);
>>> }
>>>
>>>  route[1] {
>>>
>>>
>>>          if (nat_uac_test("7")) {
>>>             fix_nated_contact();
>>>         };
>>>         # send it out now; use stateful forwarding as it works reliably
>>>         # even for UDP2TCP
>>>         xlog("L_NOTICE", " IN ROUTE BLOCK method ($rm) r-uri ($rs)
>>> :callID $ci \n");
>>>         if (!t_relay()) {
>>>                 sl_reply_error();
>>>         };
>>>         t_on_reply("1");
>>>         exit;
>>> }
>>>
>>>  onreply_route[1]{
>>>   xlog("L_NOTICE", " ON REPLY BLOCK  method ($rm) r-uri ($rs) :callID
>>> $ci :CSeq $cs \n");
>>> }
>>>
>>>
>>>
>>>  failure_route[1] {
>>>    if ( t_check_status("404|477|408|486|50[234]")){
>>>                 xlog("L_NOTICE", " ERROR RESPONSE MATCHED  method ($rm)
>>> r-uri ($rs) :callID $ci :CSeq $cs \n");
>>>          if (next_branches())
>>>          {
>>>                 xlog("L_NOTICE", " ON FAILURE BLOCK  method ($rm) r-uri
>>> ($rs) :callID $ci :CSeq $cs \n");
>>>                 t_on_failure("1");
>>>                 route(1);
>>>
>>>           }
>>>
>>>      }
>>> }
>>>
>>>
>>> -----------------------------------------------------------------------------
>>>
>>>
>>>  I attach the log of the call in debug=9 mode.
>>>
>>>
>>>  Please have a look at this if anyone can help me .
>>>
>>>  Thanx,
>>> Gomtesh
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120612/4dbcbfbc/attachment-0001.htm>


More information about the Users mailing list