[sr-dev] topoh and locally-generated requests

[Daniel-Constantin Mierla]

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
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com