#564 sip_trace module bug

1.8.x
closed-fixed
modules (454)
5
2013-01-29
2012-10-11
Dragos Oancea
No

Hi

The siptrace module reports a wrong value in the `fromip` field of the sip_trace table.

For example , for this INVITE, coming from tls:80.187.x.x:62510 , I would expect the value "tls:80.187.x.x:62510" to be added in the `fromip` field,
but it's adding "tls:80.187.x.x:625" instead . It's missing two digits from the port value.
Also , sometimes it would put its local port (in my case 5061) instead of the remote port in the `fromip` or `toip` fields.

INVITE sips:+49170738xxxx@sip.domain.com SIP/2.0
Call-Id: c64e6615c79ab23501ad13f2e1a58918@10.77.26.75
CSeq: 1 INVITE
Via: SIP/2.0/TLS 10.77.26.75:59076;branch=z9hG4bK127109c14cd3b59c9ef9909b737982ab
Max-Forwards: 70
From: "+491713xxxxx" <sips:username@sip.domain.com>;tag=yRkyOWfbq
To: <sips:+4917073xxxxx@sip.domain.com>
Contact: <sips:00xxxx@80.187.x.x:62510;transport=tls>
Allow: ACK,BYE
User-Agent: SomeUserAgent
Content-Type: application/sdp
Content-Length: 138

v=0
o=- 1349965870484 1349965870484 IN IP4 10.77.26.75
s=-
c=IN IP4 10.77.26.75
t=0 0
m=audio 37566 RTP/AVP 0
a=rtpmap:0 PCMU/8000

The problem was observed with opensips 1.8.1-tls and opensips-1.7.2-tls .

Cheers,
Dragos

Discussion

1 2 3 > >> (Page 1 of 3)
  • Can you reproduce that? if so, I will provide a small patch to print some extra logs - the idea is to see if the truncation comes from the siptrace or the mysql module

    Regards,
    Bogdan

     
    • assigned_to: nobody --> bogdan_iancu
     
  • Dragos Oancea
    Dragos Oancea
    2012-10-12

    Hi

    Yes, it happens very often,I don't know why . Sometime it puts the correct values into the fields (for messages within the same dialog I could see some entries -requests or replies - added with the correct port , but some are missing one or two digits ),

    If you provide the patch I'll apply it.

    Cheers,
    Dragos

     
  • siptrace extra logs

     
    Attachments
  • Dragos, apply this patch -> it will print to logs (on critical level) the calculated FROMIP and TOIP values. When you find bogus entries in siptrace, you can try to correlate with the log to see if the values from logs are also truncated.

    Thanks and regards,
    Bogdan

     
  • Dragos Oancea
    Dragos Oancea
    2012-10-15

    Hi Bogdan,

    INVITE sips:+4917133xxxxx@sip.domain.com SIP/2.0
    Call-Id: 6484f90259156c8d702a1cae0eb49f27@10.208.83.156
    CSeq: 1 INVITE
    Via: SIP/2.0/TLS 10.208.83.156:53912;branch=z9hG4bK2929012bef3d8abb931df26bd8fa498c
    Max-Forwards: 70
    From: "+4917073xxxxx" <sips:xxxxx@sis.secusmart.com>;tag=IhJICbbyh
    To: <sips:+4917133xxxxx@sip.domain.com>
    Contact: <sips:xxxxxx@80.187.x.x:52316;transport=tls>
    Allow: ACK,BYE
    User-Agent: SomeUserAgent
    Content-Type: application/sdp
    Content-Length: 142

    v=0
    o=- 1350298945023 1350298945023 IN IP4 10.208.83.156
    s=-
    c=IN IP4 10.208.83.156
    t=0 0
    m=audio 58639 RTP/AVP 0
    a=rtpmap:0 PCMU/8000

    | INVITE | | tls:80.187.x.x:5231 | tls:212.162.x.x:5061 | IhJICbbyh | in | 2012-10-15 13:02:24 |

    CRITICAL:siptrace:sip_trace: xXx to ip is [tls:212.162.x.x:5061]
    CRITICAL:siptrace:sip_trace: xXx from ip is [tls:80.187.x.x:52316]

    The log entries (printed with the patch you provided) look correct, the `fromip` and `toip` fields are showing truncated values in the sip_trace table for most of the request and replies.

    Cheers,
    Dragos

     
  • Could you check the table format ? Do "desc siptrace" and see what are the sizes of the fromip and toip fields in the table - maybe the truncating is done by db.

     
  • Dragos Oancea
    Dragos Oancea
    2012-10-15

    mysql> desc sip_trace ;
    +-------------+------------------+------+-----+---------------------+----------------+
    | Field | Type | Null | Key | Default | Extra |
    +-------------+------------------+------+-----+---------------------+----------------+
    | id | int(10) unsigned | NO | PRI | NULL | auto_increment |
    | date | datetime | NO | MUL | 1900-01-01 00:00:01 | |
    | callid | varchar(255) | NO | MUL | | |
    | traced_user | varchar(128) | NO | MUL | | |
    | msg | text | NO | | NULL | |
    | method | varchar(50) | NO | | | |
    | status | varchar(128) | NO | | | |
    | fromip | varchar(50) | NO | MUL | | |
    | toip | varchar(50) | NO | | | |
    | fromtag | varchar(64) | NO | | | |
    | direction | varchar(4) | NO | | | |
    | time_stamp | timestamp | NO | | CURRENT_TIMESTAMP | |
    +-------------+------------------+------+-----+---------------------+----------------+
    12 rows in set (0.01 sec)

    They are varchar(50) , there should be enough space.
    Also , sometimes the same ip:port pair is inserted correctly - for example it could we wrong for the received INVITE, but it could be correct for the relayed BYE .

     
  • Dragos Oancea
    Dragos Oancea
    2012-10-17

    Hi Bogdan,

    No , I am not using that feature.

    Regards,
    Dragos

     
1 2 3 > >> (Page 1 of 3)