Diversion header

[BceBoJlog]

Hi! Sniffer parses and adds numbers to the database only from the URIs of the "From" and "To" headers. The numbers from the "Diversion" headers are not analyzed and are not written to the database. As a result, it is impossible to find calls by the forwarding number in the database and analyze all calls forwarded from the required number.

[stuart-edge]

In my case, the call with a diversion header is completely ignored. Scenario: 61272091827 called 0414674199 and was diverted to 61294964040

INVITE sip:61294964040@203.23.175.90;user=phone SIP/2.0 Max-Forwards: 70 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: 100rel,timer To: sip:0414674199@203.23.175.90;user=phone From: sip:61272091827@203.134.21.10;tag=3871712453-1200387854 P-Asserted-Identity: sip:61272091827@203.134.21.10;user=phone Call-ID: 184363124-3871712453-1433319674@melsbc1.mydomain.com CSeq: 1 INVITE Allow: PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL Via: SIP/2.0/UDP 203.134.21.10:5060;branch=z9hG4bK1d765e14f40bac7a5014e9b4b395b868 Contact: sip:61272091827@203.134.21.10:5060;tgrp=C20-OLC1BQBNCVC Diversion: sip:0414674199@203.134.21.10;reason=no-answer;privacy=off;counter=1 Content-Type: application/sdp Accept: application/sdp Content-Length: 365

[voipmonitor]

hi please attach pcap

[stuart-edge]

61272091827-61414674199-61294964040.zip

I have some entries in filter_telnum. I tried adding two more entries to cover the numbers in the diversion header but it didn't make any difference. mysql> select * from filter_telnum; +----+-------------+-----------+-----------+------+------+------+----------+------+-------+------+------+--------+---------+--------------+------+-----------+ | id | prefix | fixed_len | direction | rtp | rtcp | sip | register | dtmf | graph | wav | skip | script | mos_lqo | hide_message | note | remove_at | +----+-------------+-----------+-----------+------+------+------+----------+------+-------+------+------+--------+---------+--------------+------+-----------+ | 49 | 61294964040 | 1 | 0 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | NULL | NULL | | 50 | 61294964026 | 1 | 0 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | NULL | NULL | | 51 | 61272091827 | 1 | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 0 | NULL | NULL | | 52 | 0414674199 | 1 | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 0 | NULL | NULL | +----+-------------+-----------+-----------+------+------+------+----------+------+-------+------+------+--------+---------+--------------+------+-----------+ 4 rows in set (0.00 sec)

[stuart-edge]

I was having a look at rfc5806 (Diversion Indication in SIP) If you were to add diversion information you would have to allow for multiple diversion headers. See the second call in the attached pcap Diversion: "Stuart Edge" sip:61294964008@203.23.175.90;reason="deflection";counter=2;privacy=off,"Test Phone" sip:61294964026@203.23.175.90;reason="unconditional";counter=1;privacy=off

call-4083-4044-0414674199.display.info.on.pcap.zip

To cover all the diversion details you may want add a new database table. EG. cdr_diversion Perhaps something like this: describe cdr_diversion; +------------------+-----------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------------+-----------------------+------+-----+---------+----------------+ | ID | bigint(20) unsigned | NO | PRI | NULL | auto_increment | | cdr_ID | bigint(20) unsigned | NO | MUL | NULL | | | diverter | varchar(255) | NO | | NULL | | | diverter_domain | varchar(255) | NO | | NULL | | | diverter_name | varchar(255) | NO | | NULL | | | reason | varchar(255) | NO | | NULL | | | counter | smallint(5) unsigned | YES | | NULL | | | limit | smallint(5) unsigned | YES | | NULL | | | privacy | varchar(255) | YES | | NULL | | | screen | varchar(255) | YES | | NULL | | | extension | varchar(255) | YES | | NULL | | +------------------+-----------------------+------+-----+---------+----------------+

I am happy to help and provide further examples or help with whatever you need.

[voipmonitor]

within one sip session there can be multiple diversion headers with different content? Creating new table would be nice but it would be too much data if the only thing to extract and store would be the 61294964026 number?

[stuart-edge]

Yes, one SIP session can have multiple diversion headers with different content. There are often multiple diversions. There are multiple parameters in each diversion. So a new database table would be the best way to record this information.

I have been dealing with this quite a lot during recent times. Australian carriers have been very strict on correct diversion information in an effort to reduce SPAM calls. There are many spammers who use fake caller IDs to make calls. If someone is attempting a call via a carrier and they do not own the caller ID they are using, the call is rejected. EG. If a call from a carrier A to carrier B arrives with a caller ID +61294964040 but carrier B recognises this call ID belongs to Carrier B, Carrier B will reject the call because the caller ID shouldn’t be coming from carrier A. To avoid valid call being rejected, diversion headers must provide the path of the call.

In the scenario below: 61272091827 called 0493363501 0493363501 diverted (reason-no-answer) to 0414674199 0414674199 diverted (reason=unknown) to 61294964040

INVITE sip:61294964040@203.23.175.90;user=phone SIP/2.0 Max-Forwards: 70 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: 100rel,timer To: sip:0493363501@203.23.175.90;user=phone From: sip:61272091827@203.134.5.10;tag=3872015738-350219619 P-Asserted-Identity: sip:61272091827@203.134.5.10;user=phone Call-ID: 172663788-3872015738-1904341676@sydsbc2.mydomain.com CSeq: 1 INVITE Allow: PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL Via: SIP/2.0/UDP 203.134.5.10:5060;branch=z9hG4bKd8d3644ae6d77678a012416bc27a1cda Contact: sip:61272091827@203.134.5.10:5060;tgrp=C20-OLC1BQBNCVC Diversion: sip:0414674199@203.134.5.10;reason=no-answer;privacy=off;counter=1 Diversion: sip:0493363501@203.134.5.10;reason=unknown;privacy=off;counter=1 Content-Type: application/sdp Accept: application/sdp Content-Length: 363

In a call centre environment we often see counter=2 (or 3) if the calls have been forward from agent to agent the externally.

[voipmonitor]

ok thank you. We have put it into the list of features which is quite long.

[stuart-edge]

Hi Martin,

Great, thanks for putting it in the list. If there is anything I can do to help, let me know. I have many years of experience in VoIP and telecommunications but I only do PERL and PHP for web services.

Best regards, Stuart Edge Main Office: +61 2 9496-4000<tel:+61294964000> Direct Phone: +61 2 9496-4040<tel:+61294964040/> Chat with us: Live Chathttps://oscc.olcs.com.au/on-line-web/contact-info.html

From: Martin Vit @.> Sent: Tuesday, 20 September 2022 5:44 PM To: voipmonitor/sniffer @.> Cc: Stuart Edge @.>; Comment @.> Subject: Re: [voipmonitor/sniffer] Diversion header (#81)

ok thank you. We have put it into the list of features which is quite long.

— Reply to this email directly, view it on GitHubhttps://github.com/voipmonitor/sniffer/issues/81#issuecomment-1251966937, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJCS7DHOKKWMCQSIKK6C27DV7FTLNANCNFSM5BCKFUAA. You are receiving this because you commented.Message ID: @.**@.>>

[stuart-edge]

Hi Martin,

Yes, one SIP session can have multiple diversion headers with different content. There are often multiple diversions. There are multiple parameters in each diversion. So a new database table would be the best way to record this information.

I have been dealing with this quite a lot during recent times. Australian carriers have been very strict on correct diversion information in an effort to reduce SPAM calls. There are many spammers who use fake caller IDs to make calls. If someone is attempting a call via a carrier and they do not own the caller ID they are using, the call is rejected. EG. If a call from a carrier A to carrier B arrives with a caller ID +61294964040 but carrier B recognises this call ID belongs to Carrier B, Carrier B will reject the call because the caller ID shouldn’t be coming from carrier A. To avoid valid call being rejected, diversion headers must provide the path of the call.

In the scenario below: 61272091827 called 0493363501 0493363501 diverted (reason-no-answer) to 0414674199 0414674199 diverted (reason=unknown) to 61294964040

INVITE @.;user=phone SIP/2.0 Max-Forwards: 70 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: 100rel,timer To: @.;user=phone> From: @.>;tag=3872015738-350219619 P-Asserted-Identity: @.;user=phone> Call-ID: @. CSeq: 1 INVITE Allow: PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL Via: SIP/2.0/UDP 203.134.5.10:5060;branch=z9hG4bKd8d3644ae6d77678a012416bc27a1cda Contact: @.:5060;tgrp=C20-OLC1BQBNCVC> Diversion: @.>;reason=no-answer;privacy=off;counter=1 Diversion: @.>;reason=unknown;privacy=off;counter=1 Content-Type: application/sdp Accept: application/sdp Content-Length: 363

In a call centre environment we often see counter=2 (or 3) if the calls have been forward from agent to agent the externally.

Best regards, Stuart Edge Main Office: +61 2 9496-4000<tel:+61294964000> Direct Phone: +61 2 9496-4040<tel:+61294964040/> Chat with us: Live Chathttps://oscc.olcs.com.au/on-line-web/contact-info.html

From: Martin Vit @.> Sent: Tuesday, 13 September 2022 2:53 AM To: voipmonitor/sniffer @.> Cc: Stuart Edge @.>; Comment @.> Subject: Re: [voipmonitor/sniffer] Diversion header (#81)

within one sip session there can be multiple diversion headers with different content? Creating new table would be nice but it would be too much data if the only thing to extract and store would be the 61294964026 number?

— Reply to this email directly, view it on GitHubhttps://github.com/voipmonitor/sniffer/issues/81#issuecomment-1244021228, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJCS7DEWMYTPYCNHADJPUULV55NYPANCNFSM5BCKFUAA. You are receiving this because you commented.Message ID: @.**@.>>