[OpenSIPS-Users] Value of PATH is not being used in next_branches() in Faliure Route
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Jun 12 18:56:59 CEST 2012
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/20120612/9ab1e980/attachment-0001.htm>
More information about the Users
mailing list