8 Oct
2019
8 Oct
'19
3:22 p.m.
Hello,
the uac_replace_from()/_to() require that the From/To headers are not
changed by the end points. The purpose is RFC3261 requirement saying
that From/To must not be changed in order to be backward compatible with
RFC2543 (previous sip specs). If the endpoints change them, then they
are not used for backward compatibility so you can changed them without
automatic restore -- just change them as you need.
If one of the endpoints still require not to have the From/To changed,
but the other endpoint in changing them, then you have to use uac module
together with dialog and store the From/To values in dialog variables
instead of the default behaviour that uses RR params -- see the readme
of uac module.
Cheers,
Daniel
On 04.10.19 20:42, Duarte Rocha wrote:
Greetings,
This is a repeated problem, but i have more info now. Please help
understand if there is a problem on my code or if there is any kind of
Kamailio bug.
On the first INVITE of every call i apply uac_replace_from() and
uac_replace_to() in order to normalize numeration. I have the
restore_mode set as "auto".
The original numeration is :
To : 351250000000
From : 351211455000
The INVITE is sent to the client with To and From like this and with
the Record-Route headers (Kamailio has 2 Ips and inserts 2
Record-Routes) containing vsf and vst parameters to help the future
restores :
To: <sip:+351250000000@111.111.111.111
<mailto:sip%3A%2B351250000000@111.111.111.111>>
From: <sip:+351211455000@111.111.111.111
<mailto:sip%3A%2B351211455000@111.111.111.111>>;tag=BD583030373631320511EAE6
Record-Route:
<sip:111.111.111.111;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62>
Record-Route:
<sip:111.111.111.111;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62>
My client, upon receiving the INVITE, also does some changes in the
numeration and sends a 183 reply with the following headers :
Record-Route:
<sip:111.111.111.111;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62>
Record-Route:
<sip:111.111.111.111;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62>
From: "+351211455000" <sip:I2116446I_500@111.111.111.111
<mailto:sip%3AI2116446I_500@111.111.111.111>>;tag=BD583030373631320511EAE6
To: <sip:+351250000000@111.111.111.111
<mailto:sip%3A%2B351250000000@111.111.111.111>>;tag=as3e46f684
After Kamailio processes the reply, To
and From are restored to it's original values and the reply is relayed :
From: <sip:351211455000@111.111.111.111
<mailto:sip%3A351211455000@111.111.111.111>>;tag=BD583030373631320511EAE6
To: <sip:351250000000@111.111.111.111
<mailto:sip%3A351250000000@111.111.111.111>>;tag=as3e46f684
Here, the restore works perfectly.
By the end of the call the client sends me a BYE request with Route,
From and To like this :
Route:
<sip:111.111.111.111;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62>,<sip:212.13.40.205;r2=on;lr;ftag=BD583030373631320511EAE6;tbk_i=2_2_Y;tbk_o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJCnNyAwMcHwIdHQsWHwUMOA--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcHwIdGgQeHAIFOQ--;did=18e.5d62>
From:
<sip:+351250000000@111.111.111.111
<mailto:sip%3A%2B351250000000@111.111.111.111>>;tag=as3e46f684
To: "+351211455000" <sip:I2116446I_500@111.111.111.111
<mailto:sip%3AI2116446I_500@111.111.111.111>>;tag=BD583030373631320511EAE6
Here, the difference between 183 and
BYE seems to be only in the Route\Record-Route are built (2 Headers or
one header with 2 uri).
Now, there are a couple of problems
relaying the BYE that seem to me to be related to auto replace.
This BYE message isn't logged on the
onsend-route and it logs a couple of errors :
ERROR: <core>
[core/parser/msg_parser.c:164]: get_hdr_field(): bad to header
ERROR: <core>
[core/parser/msg_parser.c:337]: parse_headers(): bad header field [To:
"+351211455000"
<sip:Q4525417L_<:C212.13.38.148>;tag=3DC130303736313205201F18#015#012Call-ID:
020FAAC7]
ERROR: dialog
[dlg_handlers.c:666]: pre_match_parse(): bad request or missing
CALLID/TO hdr :-/
ERROR: <core>
[core/parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected
char [<] in status 6: ["+351211455000" <sip:Q4525417L_] .
Despite not being logged on
onsend_route and creating some errors, the BYE is still relayed like
this :
From:
<sip:351250000000@111.111.111.111
<mailto:sip%3A351250000000@111.111.111.111>>;tag=as3e46f684
To: "+351211455000"
<sip:Q4525417L_<:C111.111.111.111>;tag=BD583030373631320511EAE6
This, naturally, generates a "400 Bad
Request" reply from the next equipment.
I've also logged the $tU values along
the code for BYE requests and it always logs the "I2116446I_500", so i
don't know if my code can be the cause of this.
A couple of questions and comments
- What can i do to better debug this
issue? I want to be sure if the problem comes from my code of if it is
a Kamailio issue. Right now i'm not sure where to look.
- Can a request be sent without passing
on onsend_route ? I have used this code to "catch" the BYE, which
works for other BYEs - if( $rm == "BYE") {xerr("On send : To User =
$tU");}
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Oct 21-23, 2019, Berlin, Germany -- https://asipto.com/u/kat