[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