[Serusers] Handling server with broken record-route handling

[Marcus Better]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  Hi,

I have problems with a remote server, outside of my control, that seems
to have very broken request URI handling. It is possibly suffering from
an Asterisk bug [1] or something similar.

On my side I have a UAC (IP address 172.16.1.102) and a SER 2.0 proxy.
The UAC sends an INVITE, and the remote UAS ends the dialog with a BYE
request. However this BYE returns to my proxy with missing route
headers, so SER cannot route it. I need to work around the problem with
SER on my side and wonder what the best solution is.

Here is the relevant part of the conversation as seen on my proxy
80.81.82.3 (slightly massaged, irrelevant parts cut):

INVITE sip:00463112341234 at proxy.remote.com SIP/2.0.
Record-Route: <sip:80.81.82.3;avp=Z3oDBwBhY2NvdW50AwB5ZXM;lr>.
Call-ID: f730a3a6a5c450508274739a8133ae7f at 172.16.1.102.
CSeq: 1 INVITE.
To: <sip:00463112341234 at proxy.remote.com>.
From: <sip:17473605948 at proxy.remote.com>;tag=2045565953650740630.
Via: SIP/2.0/UDP 80.81.82.3;branch=z9hG4bK761b.b1548ac4.0.
Via: SIP/2.0/UDP
172.16.1.102:5060;rport=5060;appname=myapp;branch=z9hG4bK74592b710287e6cfa94b4cf9c10e15bf.
Contact: "17473605948" <sip:172.16.1.102:5060;transport=udp>.

SIP/2.0 200 OK.
Via: SIP/2.0/UDP 80.81.82.3;branch=z9hG4bK761b.b1548ac4.0.
Via: SIP/2.0/UDP
172.16.1.102:5060;rport=5060;appname=myapp;branch=z9hG4bK74592b710287e6cfa94b4cf9c10e15bf.
Record-Route: <sip:123.12.13.14;lr;ftag=2045565953650740630>.
Record-Route: <sip:80.81.82.3;avp=Z3oDBwBhY2NvdW50AwB5ZXM;lr>.
From: <sip:17473605948 at proxy.remote.com>;tag=2045565953650740630.
To: <sip:00463112341234 at proxy.remote.com>;tag=as438ee174.
Call-ID: f730a3a6a5c450508274739a8133ae7f at 172.16.1.102.
CSeq: 1 INVITE.
Contact: <sip:011463112341234 at 130.94.88.93:5060>.

ACK sip:01146739835569 at 130.94.88.90:5060 SIP/2.0.
Record-Route: <sip:80.81.82.3;avp=Z3oDBwBhY2NvdW50AwB5ZXM;lr>.
Call-ID: f730a3a6a5c450508274739a8133ae7f at 172.16.1.102.
CSeq: 1 ACK.
Via: SIP/2.0/UDP 80.81.82.3;branch=0.
Via: SIP/2.0/UDP
172.16.1.102:5060;rport=5060;appname=myapp;branch=z9hG4bK96a96b64dfd5aba5c896c37e0de18850.
From: <sip:17473605944 at proxy.remote.com>;tag=7737826714334905221.
To: <sip:0046739835569 at proxy.remote.com>;tag=as543c9f3f.
Route: <sip:123.12.13.14;lr;ftag=7737826714334905221.
Content-Type: application/sdp.

BYE sip:80.81.82.3:5060 SIP/2.0.
Record-Route: <sip:123.12.13.14;lr;ftag=as438ee174>.
Via: SIP/2.0/UDP 123.12.13.14;branch=z9hG4bK100d.d617f387.0.
Via: SIP/2.0/UDP 130.94.88.93:5060;branch=z9hG4bK0256ad7c;rport=5060.
Route: <sip:80.81.82.3;avp=Z3oDBwBhY2NvdW50AwB5ZXM;lr>.
From: <sip:00463112341234 at proxy.remote.com>;tag=as438ee174.
To: <sip:17473605948 at proxy.remote.com>;tag=2045565953650740630.
Call-ID: f730a3a6a5c450508274739a8133ae7f at 172.16.1.102.
CSeq: 102 BYE.

I think this BYE is incorrect. It should have the originator's Contact
(sip:172.16.1.102:5060;transport=udp) in the request URI and the
Record-Routes of the original INVITE in the Route header. Or, if it is a
strict router, it could have the current request URI but add the Contact
as the last Route header. Now it has destroyed the originator's route
information. What is the best way to get SER to remember/reconstruct
this last hop to the UAC?

Cheers,

Marcus

[1] http://bugs.digium.com/view.php?id=3609
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjXkbQACgkQXjXn6TzcAQnhrQCeP9T0pR+AlPJjTr8OCS5nNOAA
GBIAnR5pw68rqe1PR00jDLvcYh+eQXPP
=sdca
-----END PGP SIGNATURE-----