1 Aug
2014
1 Aug
'14
6:03 p.m.
El 01/08/14 01:24, Daniel-Constantin Mierla escribió:
The uac from/to replacement relies that parties keep
the same from/to headers content.
The mechanism to replace A with B is to combine both and get the key X which is added in
the record-route as parameter. Then practically from A and X results B and from B and X
results A.
Now in this case, the notify comes with something different than was in SUBSCRIBE,
therefore the result is messed up.
Perhaps a check over the result to see if it is at least a good value would be useful,
but doesn't solve this issue.
If both sides in this dialog rely on RFC3261 dialog matching (call-id, from tag and to
tag), then practically after the initial SUBSCRIBE (where is no To tag), then you can
replace From/To display name and uri with anything (e.g., anonymous).
An improvement could be to know in advance that one side is not keeping From/To, then
practically storing (encrypted/encode) the intial value only. This requires C coding.
I had to patch kamailio to work around the issue. What I did is to calculate a small
(8-bit) XOR checksum of the old uri, and prepend this byte on the old uri in order to
calculate the rr parameter. On restoring, the value should match, and if it does not,
the relevant header is left unchanged.
Is this strategy worthy of submitting for merge, or is it too hacky?