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

Bogdan-Andrei Iancu bogdan at opensips.org
Mon Jun 11 16:43:34 CEST 2012


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 Developer
http://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 
> <http://sip:855_1_7agentsURI@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 
> <http://sip:855_1_7agentsURI@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 
> <http://sip:855_1_7agentsURI@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 <mailto: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 Developer
>     http://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 <http://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 <mailto: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 Developer
>>         http://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 list
>>>         Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120611/100a558c/attachment-0001.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: serialize.diff
URL: <http://lists.opensips.org/pipermail/users/attachments/20120611/100a558c/attachment-0001.asc>


More information about the Users mailing list