Juha Heinanen writes:
> send_request line correctly tells "send_request to R-URI
> <sip:[email protected]>", but further down is shown that the actual
> request uri has been changed (i guess based on next_hop) to
> sip:[email protected]:5090.
r-uri gets changed by patch_ruri_with_remote_ip() call in
core/sip/trans_layer.cpp:
INFO("R-URI before patch
<%.*s>",msg->u.request->ruri_str.len,msg->u.request->ruri_str.s);
}
string ruri; // buffer needs to be @ function scope
if((flags & SEND_REQUEST_FLAG_NEXT_HOP_RURI) &&
(patch_ruri_with_remote_ip(ruri,msg) < 0)) {
return -1;
}
INFO("R-URI after patch
<%.*s>",msg->u.request->ruri_str.len,msg->u.request->ruri_str.s);
syslog:
Sep 11 16:10:31 siika sems[27910]: [#7f4281dc1700] [send_request,
trans_layer.cpp:1095] INFO: R-URI before patch <sip:[email protected]>
Sep 11 16:10:31 siika sems[27910]: [#7f4281dc1700] [send_request,
trans_layer.cpp:1104] INFO: R-URI after patch <sip:[email protected]:5090>
before that i get to syslog:
Sep 11 16:10:31 siika sems[27910]: [#7f4281dc1700] [applyBProfile,
SBCCallLeg.cpp:370] INFO: patch_ruri_next_hop = 236
which is produced by this piece of core:
void SBCCallLeg::applyBProfile()
...
INFO("patch_ruri_next_hop = %i",call_profile.patch_ruri_next_hop);
dlg->setPatchRURINextHop(call_profile.patch_ruri_next_hop);
i have not been able to find, why value of
call_profile.patch_ruri_next_hop is true (= 236). it is because the
variable is left uninitialized somewhere?
this whole patch_ruri_next_hop business has been introduced to sems in
june. could it be that there is a bug in the new code?
-- juha
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
