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:[email protected]] Local >> request BYE to sip:[email protected]:5060 >> Nov 17 17:20:16 centosity6 /usr/local/sbin/kamailio[10357]: INFO: >> [R-TM-LOCAL-REQUEST:[email protected]] 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"[email protected]" >> 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:[email protected]:5060 SIP/2.0 >> Via: SIP/2.0/UDP >> 172.30.110.4;branch=z9hG4bK00ac.30df1375000000000000000000000000.0 >> To: <sip:[email protected]:5060>;tag=3287SIPpTag001 >> From: <sip:[email protected]:5060>;tag=2117SIPpTag015 >> CSeq: 1 BYE >> Call-ID: [email protected] >> Content-Length: 0 >> Max-Forwards: 70 >> >> >> 17:23:34.097239 IP 172.30.110.4.sip > 172.30.110.5.sip: SIP, length: 358 >> [email protected] 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:[email protected]:5060>;tag=2117SIPpTag015 >> From: <sip:[email protected]:5060>;tag=3287SIPpTag001 >> CSeq: 2 BYE >> Call-ID: [email protected] >> 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:[email protected]>;tag=3287SIPpTag001 >> To: 17069950290 <sip:[email protected]: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. >> -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
