[sr-dev] [kamailio] ERROR: topoh th_mask_decode(): invalid input string"1-4289383-6930886-1692777-3284 at 127.0.1.1" (#15)

[klistrod]

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 at 127.0.1.1] Local 
request BYE to sip:sipp at 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 at 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 at 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.... at .?]..n..........b..BYE sip:sipp at 127.0.1.1:5060 SIP/2.0 
Via: SIP/2.0/UDP 
172.30.110.4;branch=z9hG4bK00ac.30df1375000000000000000000000000.0 
To: <sip:4916095083616 at 127.0.1.1:5060>;tag=3287SIPpTag001 
From: <sip:17069950290 at 172.30.110.4:5060>;tag=2117SIPpTag015 
CSeq: 1 BYE 
Call-ID: 1-4289383-6930886-1692777-3287 at 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....... at .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 at 172.30.110.4:5060>;tag=2117SIPpTag015 
From: <sip:4916095083616 at 127.0.1.1:5060>;tag=3287SIPpTag001 
CSeq: 2 BYE 
Call-ID: 1-4289383-6930886-1692777-3287 at 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 at .@.. ..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 at 172.30.110.4>;tag=3287SIPpTag001 
To: 17069950290 <sip:17069950290 at 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:
https://github.com/kamailio/kamailio/issues/15
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20141224/32d8dd85/attachment-0001.html>