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.
Hello,
it seems that only dealing with callid in callee side is affected, I will think of what can be done.
Cheers, Daniel
On 17/11/14 23:26, Alex Balashov wrote:
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.
To conclude this discussion specific to sr-dev, I pushed fixes to git master branch on this issue, code changes being in dialog module as well.
Cheers, Daniel
On 18/11/14 08:01, Daniel-Constantin Mierla wrote:
Hello,
it seems that only dealing with callid in callee side is affected, I will think of what can be done.
Cheers, Daniel
On 17/11/14 23:26, Alex Balashov wrote:
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.
-
Alex Balashov -
Daniel-Constantin Mierla