-----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@proxy.remote.com SIP/2.0. Record-Route: sip:80.81.82.3;avp=Z3oDBwBhY2NvdW50AwB5ZXM;lr. Call-ID: f730a3a6a5c450508274739a8133ae7f@172.16.1.102. CSeq: 1 INVITE. To: sip:00463112341234@proxy.remote.com. From: sip:17473605948@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@proxy.remote.com;tag=2045565953650740630. To: sip:00463112341234@proxy.remote.com;tag=as438ee174. Call-ID: f730a3a6a5c450508274739a8133ae7f@172.16.1.102. CSeq: 1 INVITE. Contact: sip:011463112341234@130.94.88.93:5060.

ACK sip:01146739835569@130.94.88.90:5060 SIP/2.0. Record-Route: sip:80.81.82.3;avp=Z3oDBwBhY2NvdW50AwB5ZXM;lr. Call-ID: f730a3a6a5c450508274739a8133ae7f@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@proxy.remote.com;tag=7737826714334905221. To: sip:0046739835569@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@proxy.remote.com;tag=as438ee174. To: sip:17473605948@proxy.remote.com;tag=2045565953650740630. Call-ID: f730a3a6a5c450508274739a8133ae7f@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