John Quick wrote:
The UAS at 10.30.9.11 has failed to process the two Record-Route headers
sent in the INVITE. It should send the Route Set back as part of the
Response - i.e. within the 200 OK. But it hasn't. It has just absorbed the
Record-Route headers and ignored them. I would say that is faulty UAS
behaviour, but maybe Bogdan could confirm.
Hi John,
thanks for the reply. Your explanation makes sense to me; I can see that
in the packet capture file, in the replies from the UAS in packets 4 and
6.
Also, your article explains why OpenSIPS adds two RR headers in this
scenario.
Consequently, the ACK has no Route headers. That means OpenSIPS is treated
as the final destination - it doesn't know that it is meant to relay the ACK
to 10.30.9.11
Now I have the right keywords to search for some more information; it
looks like there was an attempt to fix this in 2006:
https://sourceforge.net/p/sipp/mailman/sipp-users/thread/200606071744.k57HiPJ4002550%40mail.zserv.tuwien.ac.at/#msg9012298
But then there is
http://yuminstallgit.blogspot.com/2011/03/record-route-and-route-fun-in-sipp.html
and the comment from 2021 at the end suggests others have seen the same
issue relatively recently.
If you can't fix the UAS, you could try using the Topology hiding module in
OpenSIPS. That would probably overcome the problem because Topology hiding
doesn't send Record-Route headers downstream.
That gives me a few options; I'll try replacing the SIPp UAS with
FreeSWITCH. This may sound a bit over-engineered, as all I need is a
machine that automatically answers calls to a bunch of usernames and
plays an audio file. But it gives me a scenario that vaguely resembles a
real-world setup, to test against.
Thanks,
Thomas
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
