While making an basic call with uac_reg User though kamailio, the FROM Uri gets re-written within the Bye message. Here according code it should xor the old uri with new uri. But it seems the old uri is damaged or read from non valid string.
We have this issue in Live environment and in DEV. Funny part is the string seems to be always the same on one system, but different between the systems. In our DEV the string Contains a " which brings the from URI Parser to crash. On Live there are only valid letters so it's just damaged, but the Bye is working.
Attached you can find a trace from that scenario Basic call A to B and B Answers the call and Hangs up. The bye is sedn OK to Kamailio and the Bye from Kamailio to A is broken (from uri).
Logs with debug level 1 and 5 are also attached. We are able to reproduce it in our development setup so we can make retests all the time. [kamailio_prob.zip](https://github.com/kamailio/kamailio/files/555579/kamailio_prob.zip)
The design of uac_replace_from() with record-route parameters is expecting that From/To headers are not changed. If that is done, then the endpoint is supporting the rfc3261 and restore should not be needed - e.g., change only for the initial invite and for the rest change the from/to to anonymous values.
If one of the devices is not rfc3261, the solution is to use the other mechanism from uac_replace_from(), that stores the initial values in dialog variables and don't rely on sip message at all.
For clarification: "brings the from URI Parser to crash" -- what do you mean by that? Like throwing errors or causing a crash? The first is ok, the second needs to be fixed. For first case, perhaps it's still some space for improvements, eg., check if the result has only allowed chars in order to do replacement, otherwise just write error logs and keep the old value.
i think in this case the kamailio does not need to change the From Header at all. But for any reasons i compares old with new URI (according the code) During this the kamailio changes the From header to this: ``` <sip:127A946"0DDloqbpiumQD ```
There are lots of failure messages in the log describing exactly this. On kamailio except for the error message nothing breaks. On the A side of the call (in our case an asterisk) the Bye gets pardes and here the parser stops at the quotes. This is not an allowed character in a SIP URI and the Parser ends with an error and reply back with "Bad Request"
As far as i understand SIP the change by kamailio of the from URI is not needed in this case and causes a hanging call.
Hi, maybe one more hint, we do not change the FROM Header on intention. According config the Bye gets routet by our loose_route which only makes some xlog, rtpengine stuff and t_relay. We du not use any uac_rewrite mechanism.
maybe we are doing something wrong, but i cannot find anything we could have done.
If you change for the initial invite and the restore mode is auto, then it will be changed for all requests within the dialog, including the bye. You can change the restore mode parameter for uac module.
ok, i'll try that. But should it work with the auto mode? I would say even if i have auto mode the Bye From header should not be destroyed.
for our setup it's working with restore mode manually. I'll test the other call scenarios if we need to restore the From header some where.
thanks for the hint!
Yes, the auto mode needs a safety check fix, so it doesn't break the messages.
I pushed a patch for it, hopefully it's going to catch the situation and throw some warnings in the logs, instead of breaking the sip message.
I am closing this one, but some testing would be very appreciated and if all ok, then I will backport.
it's working.... thanks!
Closed #833.
-
Daniel-Constantin Mierla -
vinzens