27 Oct
2016
27 Oct
'16
2:16 p.m.
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/kamail…
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833
28 Oct
28 Oct
2:34 p.m.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833#issuecomment-256898683
2:50 p.m.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833#issuecomment-256901104
31 Oct
31 Oct
10:03 a.m.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833#issuecomment-257233989
10:15 a.m.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833#issuecomment-257235806
10:31 a.m.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833#issuecomment-257238312
10:36 a.m.
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!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833#issuecomment-257239144
12:03 p.m.
Yes, the auto mode needs a safety check fix, so it doesn't break the messages.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833#issuecomment-257255378
2:57 p.m.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833#issuecomment-257286980
3:56 p.m.
it's working.... thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833#issuecomment-257299936
3:56 p.m.
Closed #833.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/833#event-841925963
2974
days inactive
2978
days old
10 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
vinzens