Re: [sr-dev] topoh and locally-generated requests

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&quot;1-4289383-6930886-1692777-3284(a)127.0.1.1&quot; > 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(a)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(a)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. >