[SR-Users] Bad BYE request
Daniel-Constantin Mierla
miconda at gmail.com
Tue Oct 8 15:22:25 CEST 2019
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 at 111.111.111.111
> <mailto:sip%3A%2B351250000000 at 111.111.111.111>>
>
> From: <sip:+351211455000 at 111.111.111.111
> <mailto:sip%3A%2B351211455000 at 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 at 111.111.111.111
> <mailto:sip%3AI2116446I_500 at 111.111.111.111>>;tag=BD583030373631320511EAE6
>
> To: <sip:+351250000000 at 111.111.111.111
> <mailto:sip%3A%2B351250000000 at 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 at 111.111.111.111
> <mailto:sip%3A351211455000 at 111.111.111.111>>;tag=BD583030373631320511EAE6
>
> To: <sip:351250000000 at 111.111.111.111
> <mailto:sip%3A351250000000 at 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 at 111.111.111.111
> <mailto:sip%3A%2B351250000000 at 111.111.111.111>>;tag=as3e46f684
>
> To: "+351211455000" <sip:I2116446I_500 at 111.111.111.111
> <mailto:sip%3AI2116446I_500 at 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 at 111.111.111.111
> <mailto:sip%3A351250000000 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20191008/63fd05e1/attachment.html>
More information about the sr-users
mailing list