17 Mar
2009
17 Mar
'09
1:57 p.m.
I have a 0.9.6 SER proxy running and one particular UA that is creating some problems with
a RECORD-ROUTE header I am not handling correctly. Here is how I have my record_route
configured (XXXs are replaced by my actual proxy IP):
if (!(uri=~^"sip:XXX.XXX.XXX.XXX"))
{
record_route_preset("XXX.XXX.XXX.XXX:5060;nat=yes");
};
When inbound traffic arrives for this particular UA, the INVITE is passed along. when the
200 OK comes back, there is a Record-Route header that looks like this (YYYs are replaced
with the UA's public IP):
RECORD-ROUTE: <sip:YYY.YYY.YYY.YYY:5060;lr;transport=udp>
Instead of adding a new Record-Route header with my IP before this one, the message is
simply proxied back to the call origination. The ACK is then sent DIRECTLY to the UA,
bipassing my proxy...as well as the BYE/200 OK that terminates the call....thus rendering
my stateful proxy as stateless.
Can I remove the RECORD-ROUTE that my terminating UA is attaching? If not, why am I not
adding my own Record-Route header like normal?
What am I missing?
Thanks,
Steve
_________________________________________________________________
Windows Live™ Groups: Create an online spot for your favorite groups to meet.
http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009
17 Mar
17 Mar
2:16 p.m.
Hi Stephen,
I have a 0.9.6 SER proxy running and one particular UA that is creating
some problems with a RECORD-ROUTE header I am not handling correctly.
Here is how I have my record_route configured (XXXs are replaced by my
actual proxy IP):
if (!(uri=~^"sip:XXX.XXX.XXX.XXX"))
{
record_route_preset("XXX.XXX.XXX.XXX:5060;nat=yes");
};
When inbound traffic arrives for this particular UA, the INVITE is passed
along. when the 200 OK comes back, there is a Record-Route header that
looks like this (YYYs are replaced with the UA's public IP):
RECORD-ROUTE: <sip:YYY.YYY.YYY.YYY:5060;lr;transport=udp>
This client is really broken. Kick the a** of the vendor.
Instead of adding a new Record-Route header with my IP
before this one,
the message is simply proxied back to the call origination. The ACK is
then sent DIRECTLY to the UA, bipassing my proxy...as well as the BYE/200
OK that terminates the call....thus rendering my stateful proxy as
stateless.
Can I remove the RECORD-ROUTE that my terminating UA is attaching? If
not, why am I not adding my own Record-Route header like normal?
What am I missing?
Record-Route headers are inserted into the request, the INVITE in this
case, and the UAS is suppose to copy the Record-Route header from the
INVITE into the reply. Which it obviously fails to do.
In general a proxy like SER is not suppose to change/touch the reply ;-)
If you really have to support such a broken client, and you can get the
client get fixed, I would recommend you to try to modify the Record-Route
header in the on_reply route. Most likely you will have to rely on the
textops module here. I'm not entirely sure if it will work, but
theoretically you should be able to remove the broken Record-Route header
and insert a correct one.
Greetings
Nils Ohlmeier
6:15 p.m.
Nils Ohlmeier wrote:
Record-Route headers are inserted into the request, the INVITE in this
case, and the UAS is suppose to copy the Record-Route header from the
INVITE into the reply. Which it obviously fails to do.
In general a proxy like SER is not suppose to change/touch the reply ;-)
I seem to remember that there were quite legal cases where a proxy
messes with the Record-Route it added itself in the reply. Just can't
remember quite what it was.
If one doesn't need the ability of the rr module to store attributes in
the Record-Route header, one should get away with something like
append_to_reply("Record-Route: <XXX.XXX.XXX.XXX:5060;nat=yes>\r\n");
in this case.
Regards,
Martin
5778
days inactive
5778
days old
2 comments
3 participants
participants (3)
-
Martin Hoffmann -
Nils Ohlmeier -
Stephen Helfen