Hello Jose,
it is pretty hard to watch the netwok trace you send, next time please
save it as pcap file so I can loaded easily in ethereal or use ngrep
which gives more compact information.
Anyhow, there is something bad with the 10.161.14.59.
The invite comes from 10.161.14.105:20, goes through 10.161.14.59 to
openser which is 10.161.14.110. OpenSER sends back to 10.161.14.59 and
this device sends it to 10.161.14.105:6030.
CANCEL comes to 10.161.14.59 (this changes R-URI and this is not right),
goes to openser (which sets the R-URI as it was in the INVITE forwarded
by it) and then back to 10.161.14.59. The 10.161.14.59 response with
"call leg transaction does not exists" while it should be. From OpenSER
side, everything was OK, the CANCEL matched the initial INVITE
transaction and it forwarded the CANCEL properly.
My guess is that 10.161.14.59 messes the two dialogs it keeps. What is
the device running on 10.161.14.59? It does not add any signature.
Cheers,
Daniel
On 01/31/06 13:22, Jose Antonio Garvayo wrote:
Hello,
I have attached the tcpdump log, and a call flow diagram, I hope it
will be useful.
Maybe the problem is that the cancel request uri does not match the
invite request uri. But I tried putting modparam("tm",
"ruri_matching", 0) and it didn't work.
This is the openser.cfg: