[OpenSIPS-Users] Transaction matching issues

[Brett Nemeroff]

Hello List,
I'm seeing some odd issues on a few of my installs. This particular issue
I've seen on both a recent trunk (few days ago) and 1.6.4-notls. I have two
issues. I'm not sure if they are related; so I'm going to post them both in
this email

I use uac_replace_* functions quite a bit. I'm not sure if that has any
direct bearing on the issue.

First issue, BYEs don't seem to be routed WHEN the provider drops the port
off the FROM URI in the BYE message.. For example.. If the ACK to the
provider looked like this:
ACK sip:12012345678 at 22.33.12.41:5060 SIP/2.0
Via: SIP/2.0/UDP 11.22.33.147;branch=z9hG4bKe604.acce086.2
Via: SIP/2.0/UDP 11.22.33.140;branch=z9hG4bKe604.2955a671.2
Via: SIP/2.0/UDP
99.88.77:5010;received=99.88.77;branch=z9hG4bK1cb6dbbb;rport=5010
From: "10000001234" <sip:10000001234 at 99.88.77:5010>;tag=as21552672
To: <sip:12012345678 at 11.22.33.147:5060>;tag=gK0296dd86
Contact: <sip:10000001234 at 99.88.77:5010>
Call-ID: 6b2715755314cbb6427db86a7532a379 at 99.88.77
CSeq: 103 ACK
Max-Forwards: 68
Content-Length: 0

Here's the BYE, notice the port is missing on the TO (This BYE is ignored)
BYE sip:10000001234 at 99.88.77:5010 SIP/2.0
Via: SIP/2.0/UDP 22.33.12.41:5060;branch=z9hG4bK02B6745468476adab1b
From: "12012345678" <sip:12012345678 at 11.22.33.147>;tag=gK0296dd86
To: "10000001234" <sip:10000001234 at 99.88.77>;tag=as21552672
Call-ID: 6b2715755314cbb6427db86a7532a379 at 99.88.77
CSeq: 6202 BYE
Max-Forwards: 70
Route: <sip:11.22.33.147:5060
;lr;ftag=as21552672;vst=AAAAAAELCQkDCwcCAwkAcwYCGXECHBwADAADBQ4UBAQGCjUwNjA-;did=d91.b2a40bc7>
Route: <sip:11.22.33.140:5060;lr=on>
Reason: Q.850;cause=16
Content-Length: 0


Second issue, on auto-restore, I'm seeing "crap" inserted into the from
header.
Call hanging up, BYE from provider
BYE sip:15161234567 at 76.216.204.224:47972;transport=udp SIP/2.0
Via: SIP/2.0/UDP 22.33.44.41:5060;branch=z9hG4bK02Bc92370434d4b0988
From: "15125551212" <sip:15125551212 at 11.22.33.147
;transport=udp>;tag=gK02e9c8af
To: "15161234567" <sip:15161234567 at 11.22.33.140>;tag=f357d61f
Call-ID: NjhjOWVmZWI3MzMyMTJkZDQyNDBhZmRmOTBiMzVlZmE.
CSeq: 18383 BYE
Max-Forwards: 70
Route: <sip:11.22.33.147:5060
;lr;ftag=f357d61f;vst=AAAAAAIFAQIDBQIBCggHcw8KGnECHBwADAADBQ4UBAQGMDt0cmFuc3BvcnQ9dWRw;did=643.afa2e58>
Route: <sip:11.22.33.140:5060;lr=on>
Reason: Q.850;cause=16
Content-Length: 0

Relayed onto a opensips dispatcher (headed out to customer)

BYE sip:15161234567 at 76.216.204.224:47972;transport=udp SIP/2.0
Via: SIP/2.0/UDP 11.22.33.147;branch=z9hG4bK926.6d22be12.0
Via: SIP/2.0/UDP 22.33.44.41:5060;branch=z9hG4bK02Bc92370434d4b0988
From: "15125551212" <sip:300015125551212 at 11.22.33
/pvg^H[04][1d][13][1a]N[05][0b][02]t=udp>;tag=gK02e9c8af
To: "15161234567" <sip:15161234567 at 11.22.33.140>;tag=f357d61f
Call-ID: NjhjOWVmZWI3MzMyMTJkZDQyNDBhZmRmOTBiMzVlZmE.
CSeq: 18383 BYE
Max-Forwards: 69
Route: <sip:11.22.33.140:5060;lr=on>
Reason: Q.850;cause=16
Content-Length: 0

Notice the even the uri-param transport=udp is messed up in mid-word (t=udp)


Any ideas here? It almost appears to be pre-3261 trans matching. But I
wouldn't have expected that as a default..

Thanks,
Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110516/1fe31f30/attachment.htm>