[OpenSIPS-Users] Value of PATH is not being used in next_branches() in Faliure Route
Bogdan-Andrei Iancu
bogdan at opensips.org
Wed Jun 13 13:21:15 CEST 2012
Hi Gomtesh,
Just updated on SVN (1.7 , 1.8 and trunk)
Regards,
Bogdan
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 06/13/2012 01:31 PM, Gomtesh Jain wrote:
> Thanx, Bogdan It is working fine now.
>
>
>
> On Tue, Jun 12, 2012 at 10:26 PM, Bogdan-Andrei Iancu
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
> Hi Gomtesh,
>
> The bogus contact is not related to serialization stuff - as it is
> not touching the contact header at all.
>
> I suspect you have a script error and you call twice a function to
> fix / replace the contact hdr - like fix_nated_contact(). Count
> you check that ?
>
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 06/12/2012 02:04 PM, Gomtesh Jain wrote:
>> 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
>> <http://ip:855_1_7ag@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 <mailto: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 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/20120613/703d816a/attachment-0001.htm>
More information about the Users
mailing list