Reply to this email directly or view it on GitHub.
Hello,
I have found that topoh does not seem to operate correctly on
locally-generated requests, such as dialog timeout-fired BYEs.
e.g.
Nov 17 17:20:16 centosity6 /usr/local/sbin/kamailio[10357]: INFO:
[R-TM-LOCAL-REQUEST:1-4289383-6930886-1692777-3284@127.0.1.1] Local
request BYE to sip:sipp@127.0.1.1:5060
Nov 17 17:20:16 centosity6 /usr/local/sbin/kamailio[10357]: INFO:
[R-TM-LOCAL-REQUEST:1-4289383-6930886-1692777-3284@127.0.1.1] Local
request BYE to sip:172.30.110.5:5060;transport=UDP
Nov 17 17:20:16 centosity6 /usr/local/sbin/kamailio[10348]: ERROR: topoh
[th_mask.c:165]: th_mask_decode(): invalid input
string"1-4289383-6930886-1692777-3284@127.0.1.1"
Nov 17 17:20:16 centosity6 /usr/local/sbin/kamailio[10348]: ERROR: topoh
[th_msg.c:484]: th_unmask_callid(): cannot decode callid
You can see these BYEs are not TOPOH'd at all:
17:23:34.097128 IP 172.30.110.4.sip > 127.0.1.1.sip: SIP, length: 346
E..v....@.?]..n..........b..BYE sip:sipp@127.0.1.1:5060 SIP/2.0
Via: SIP/2.0/UDP
172.30.110.4;branch=z9hG4bK00ac.30df1375000000000000000000000000.0
To: sip:4916095083616@127.0.1.1:5060;tag=3287SIPpTag001
From: sip:17069950290@172.30.110.4:5060;tag=2117SIPpTag015
CSeq: 1 BYE
Call-ID: 1-4289383-6930886-1692777-3287@127.0.1.1
Content-Length: 0
Max-Forwards: 70
17:23:34.097239 IP 172.30.110.4.sip > 172.30.110.5.sip: SIP, length: 358
E.......@.V...n...n......n5.BYE sip:172.30.110.5:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP
172.30.110.4;branch=z9hG4bKdf9c.08ed9677000000000000000000000000.0
To: sip:17069950290@172.30.110.4:5060;tag=2117SIPpTag015
From: sip:4916095083616@127.0.1.1:5060;tag=3287SIPpTag001
CSeq: 2 BYE
Call-ID: 1-4289383-6930886-1692777-3287@127.0.1.1
Content-Length: 0
Max-Forwards: 70
in contrast to the other messages in this dialog:
7:23:30.871062 IP 172.30.110.5.sip > 172.30.110.4.sip: SIP, length: 844
E..h!5@.@.. ..n...n......Th.SIP/2.0 200 OK
Via: SIP/2.0/UDP
172.30.110.4;branch=z9hG4bK00ac.127fd0993a0e4c8a82474038472e09d2.0,
SIP/2.0/UDP
172.30.110.4;branch=z9hG4bKsr-goq-nEDchKUa9vuehzD2nruchwxHmrgFJru63LarksqBks-Uhz3WnrhFnrPHhKxWmd9D0s97YrRS3LvcjBeUXrqi9E9SwWoEhre2nzPRhu**
From: sipp sip:4916095083616@172.30.110.4;tag=3287SIPpTag001
To: 17069950290 sip:17069950290@172.30.110.4:5060;tag=2117SIPpTag015
Call-ID: CSEVhwoohreOhEeEnzjOhEuxmGjRhzjOhr32JWoEhre2-GPWJWxFnrPch-**
Record-Route:
sip:172.30.110.4;lr=on;ftag=3287SIPpTag001;fromcor=ejFwbUZxUmpUUFNBejFwbUZxUm9RUFBfZS5wZ111ZFo-;dlgcor=9c9.77a1
CSeq: 1 INVITE
Contact: sip:172.30.110.5:5060;transport=UDP
Content-Type: application/sdp
Content-Length: 135
v=0
o=user1 53655765 2353687637 IN IP4 172.30.110.5
s=-
c=IN IP4 172.30.110.5
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Maybe this is not possible to fix because of where topoh intercepts the
messages (transparently to the config script writer) in relation to how
the TM API is used to generate spoof requests. I just thought I would
report it.
—
Reply to this email directly or view it on GitHub.