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:[email protected]:28056sip:[email protected]:28056 <http://ip:[email protected]:28056>>
It appends the caller's contact 2 times .
Thanx,
Gomtesh
On Mon, Jun 11, 2012 at 8:13 PM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> 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:[email protected]: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:[email protected]:5506
<http://sip:[email protected]: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:[email protected]:5506
<http://sip:[email protected]: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:[email protected]:5506
<http://sip:[email protected]: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
<[email protected] <mailto:[email protected]>> 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:[email protected]: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:[email protected]: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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
