[sr-dev] topoh and locally-generated requests

[Daniel-Constantin Mierla]

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 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.
>>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda