feature code *67 (privacy) does not work.

409 views
Skip to first unread message

Fereshteh Baghaee

unread,
Oct 11, 2013, 10:26:48 AM10/11/13
to 2600h...@googlegroups.com
It does not block the caller id. Checked the log, nothing is failed or something. Call was set as privacy but it pass through the caller id.
Any thought.
Thanks. 

Darren Schreiber

unread,
Oct 11, 2013, 12:22:13 PM10/11/13
to 2600h...@googlegroups.com
Please show an example of the SIP packets…

--
You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Fereshteh Baghaee

unread,
Oct 16, 2013, 10:02:09 AM10/16/13
to 2600h...@googlegroups.com
 9.317610 204.101.104.248 -> 204.101.104.254 SIP/SDP Request: INVITE sip:*674166...@204.101.1.5:5060, with session description
  9.318230 204.101.104.254 -> 204.101.104.248 SIP Status: 100 Trying
  9.318974 204.101.104.254 -> 204.101.104.248 SIP Status: 407 Proxy Authentication Required
  9.319196 204.101.104.248 -> 204.101.104.254 SIP Request: ACK sip:*674166...@204.101.1.5:5060
  9.448725 204.101.104.248 -> 204.101.104.254 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=7353)
  9.449413 204.101.104.254 -> 204.101.104.248 SIP Status: 100 Trying
  9.483660 204.101.104.254 -> 204.101.104.248 SIP Request: NOTIFY sip:use...@204.101.1.1:6457;transport=udp
  9.546787 204.101.104.248 -> 204.101.104.254 SIP Status: 200 OK
 10.851326 204.101.104.254 -> 74.205.223.131 SIP/SDP Request: INVITE sip:14166...@trunkingserver.com, with session description
 10.876641 74.205.223.131 -> 204.101.104.254 SIP Status: 100 trying -- your call is important to us
 10.885331 204.101.104.254 -> 204.101.104.248 SIP Request: NOTIFY sip:use...@204.101.1.1:6457;transport=udp
 10.908137 204.101.104.248 -> 204.101.104.254 SIP Status: 200 OK
 13.702136 204.101.104.248 -> 204.101.104.254 SIP Request: REGISTER sip:204.101.1.5:5060
 13.706277 204.101.104.254 -> 204.101.104.248 SIP Status: 200 OK    (1 bindings)
 13.964127 204.101.104.248 -> 204.101.104.254 SIP Request: OPTIONS sip:204.101.1.5:5060
 13.964447 204.101.104.254 -> 204.101.104.248 SIP Status: 200 OK

Darren Schreiber

unread,
Oct 16, 2013, 10:46:21 AM10/16/13
to 2600h...@googlegroups.com
Hi there,
This log is not helpful.

Please provide the full SIP traces with the actual SIP packets, along with the apps and FreeSWITCH logs

From: Fereshteh Baghaee <fereshte...@gmail.com>
Reply-To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Date: Wednesday, October 16, 2013 7:02 AM
To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
--

Fereshteh Baghaee

unread,
Oct 16, 2013, 11:54:50 AM10/16/13
to 2600h...@googlegroups.com
from freeswitch:
 
2013-10-16 15:17:21.920508 [INFO] sofia.c:8180 204.101.1.8 is a proxy according to the authoritative acl
2013-10-16 15:17:21.920508 [WARNING] sofia_reg.c:1457 SIP auth challenge (INVITE) on sofia profile 'sipinterface_1' for [*674166...@mifone.ca] from ip 204.101.1.8
2013-10-16 15:17:22.030504 [INFO] sofia.c:8180 204.101.1.8 is a proxy according to the authoritative acl
2013-10-16 15:17:22.030504 [NOTICE] switch_channel.c:941 New Channel sofia/sipinterface_1/use...@mifone.ca:5060 [d7fe5cafcba4b423]
2013-10-16 15:17:22.030504 [INFO] mod_dialplan_xml.c:485 Processing user_zdgwvg <user_zdgwvg>->*674166248187 in context context_2
2013-10-16 15:17:22.060505 [NOTICE] mod_dptools.c:1485 log|d7fe5cafcba4b423|ecal...@app.mifone.ca won call control
2013-10-16 15:17:22.060505 [NOTICE] handle_msg.c:797 log|d7fe5cafcba4b423|executing export ecallmgr_Billing-ID=72dd1cc3de0e0f57508a64c541ffcf9d
2013-10-16 15:17:22.060505 [NOTICE] handle_msg.c:797 log|d7fe5cafcba4b423|executing set ecallmgr_Billing-ID=72dd1cc3de0e0f57508a64c541ffcf9d
2013-10-16 15:17:22.090507 [NOTICE] handle_msg.c:797 log|d7fe5cafcba4b423|executing multiset ^^|effective_caller_id_name=Halex|effective_caller_id_number=9057636529|ecallmgr_Billing-ID=72dd1cc3de0e0f57508a64c541ffcf9d|ecallmgr_Username=user_zdgwvg|ecallmgr_Realm=mifone.ca|ecallmgr_Account-ID=9fface975564c3cba055a3ff9c7ff593|ecallmgr_Authorizing-ID=041cdfa8cc30bde64160508dbc6839e2|ecallmgr_Authorizing-Type=device|ecallmgr_Owner-ID=46e039f79c3502df43c918b5835f9d7c|ecallmgr_Inception=on-net
2013-10-16 15:17:22.120506 [NOTICE] handle_msg.c:797 log|d7fe5cafcba4b423|executing privacy full
2013-10-16 15:17:23.380507 [NOTICE] handle_msg.c:814 log|d7fe5cafcba4b423|building xferext extension: export hold_music=${hold_music}
2013-10-16 15:17:23.380507 [NOTICE] handle_msg.c:814 log|d7fe5cafcba4b423|building xferext extension: set import=hold_music
2013-10-16 15:17:23.380507 [NOTICE] handle_msg.c:814 log|d7fe5cafcba4b423|building xferext extension: set failure_causes=NORMAL_CLEARING,ORIGINATOR_CANCEL,CRASH
2013-10-16 15:17:23.380507 [NOTICE] handle_msg.c:814 log|d7fe5cafcba4b423|building xferext extension: set continue_on_fail=true
2013-10-16 15:17:23.380507 [NOTICE] handle_msg.c:814 log|d7fe5cafcba4b423|building xferext extension: bridge {call_timeout=60,ecallmgr_Bridge-ID='e282c9656e3770ddd2e7c162cc808f0e',local_var_clobber='true'}[sip_auth_password='',sip_auth_username='',ecallmgr_Global-Resource='false',ecallmgr_Resource-ID='324111e00dc083446ec140eda7af8fc9',ignore_display_updates='true',sip_from_uri='sip:90576...@mifone.ca',ecallmgr_Reseller-ID='5abd1c820ce83b9bb314dffdbebf16c1',ecallmgr_Account-ID='9fface975564c3cba055a3ff9c7ff593',absolute_codec_string='^^:PCMU:PCMA',leg_progress_timeout='10',effective_caller_id_number='9057636529',effective_caller_id_name='Halex']sofia/sipinterface_1/14166...@trunkingserver.com
2013-10-16 15:17:23.380507 [NOTICE] handle_msg.c:814 log|d7fe5cafcba4b423|building xferext extension: event Event-Name=CUSTOM,Event-Subclass=whistle::masquerade,whistle_event_name=CHANNEL_EXECUTE_COMPLETE,whistle_application_name=bridge
2013-10-16 15:17:23.380507 [NOTICE] handle_msg.c:814 log|d7fe5cafcba4b423|building xferext extension: park
2013-10-16 15:17:23.380507 [NOTICE] handle_msg.c:817 log|d7fe5cafcba4b423|transfered call to xferext extension
2013-10-16 15:17:23.390506 [NOTICE] switch_channel.c:941 New Channel sofia/sipinterface_1/14166...@trunkingserver.com [0ed220d6-3676-11e3-99df-273c0468ce4c]
2013-10-16 15:17:23.390506 [INFO] switch_nat.c:590 NAT port mapping disabled
2013-10-16 15:17:23.390506 [INFO] switch_nat.c:590 NAT port mapping disabled
2013-10-16 15:17:28.230506 [NOTICE] sofia_glue.c:4176 Pre-Answer sofia/sipinterface_1/14166...@trunkingserver.com!
2013-10-16 15:17:28.230506 [INFO] switch_ivr_originate.c:3309 Sending early media
2013-10-16 15:17:28.230506 [NOTICE] sofia_glue.c:4176 Pre-Answer sofia/sipinterface_1/use...@mifone.ca:5060!
2013-10-16 15:17:28.830505 [INFO] switch_rtp.c:3577 Auto Changing port from 204.101.1.8:5000 to 204.101.1.3:8960
 
 
sip trace:
U 2013/10/16 15:20:30.080669 204.101.104.130:58188 -> 204.101.1.8:5060
INVITE sip:*674166...@mifone.ca:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.154;branch=z9hG4bK456576609f1ee6272.
Max-Forwards: 70.
From: <sip:user_z@.mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166...@mifone.ca:5060>.
Call-ID: d7fe5cafcba4b423.
CSeq: 9284 INVITE.
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO.
Allow-Events: talk, hold, conference, LocalModeStatus.
Contact: <sip:user_...@204.101.1.1:58188;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D204DDB>".
Supported: path, 100rel, replaces.
User-Agent: Aastra 53i/3.2.2.3077.
Content-Type: application/sdp.
Content-Length: 306.
.
v=0.
o=MxSIP 0 1 IN IP4 192.168.1.154.
s=SIP Call.
c=IN IP4 192.168.1.154.
t=0 0.
m=audio 5000 RTP/AVP 0 8 18 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=silenceSupp:off - - - -.
a=fmtp:18 annexb=no.
a=fmtp:101 0-15.
a=ptime:30.
a=sendrecv.

U 2013/10/16 15:20:30.081055 204.101.1.8:5060 -> 204.101.1.3:58188
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 192.168.1.154;branch=z9hG4bK456576609f1ee6272;rport=58188;received=204.101.1.3.
From: <sip:use...@mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166...@mifone.ca:5060>.
Call-ID: d7fe5cafcba4b423.
CSeq: 9284 INVITE.
Server: Mifone Platform.
Content-Length: 0.
.
U 2013/10/16 15:20:30.081090 204.101.1.8:5060 -> 204.101.1.3:5060
INVITE sip:*674166...@204.101.1.3:5060 SIP/2.0.
Record-Route: <sip:204.101.1.8;lr=on;ftag=20b49f01fa>.
Via: SIP/2.0/UDP 204.101.1.8;branch=z9hG4bKa8db.e6beef1.0.
Via: SIP/2.0/UDP 192.168.1.154;rport=58188;received=204.101.1.3;branch=z9hG4bK456576609f1ee6272.
Max-Forwards: 30.
From: <sip:user_z@.mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166248187@.mifone.ca:5060>.
Call-ID: d7fe5cafcba4b423.
CSeq: 9284 INVITE.
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO.
Allow-Events: talk, hold, conference, LocalModeStatus.
Contact: <sip:user_...@204.101.1.3:58188;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D204DDB>".
Supported: path, 100rel, replaces.
User-Agent: Aastra 53i/3.2.2.3077.
Content-Type: application/sdp.
Content-Length: 366.
X-AUTH-IP: 204.101.1.3.
.
v=0.
o=MxSIP 0 1 IN IP4 204.101.1.3.
s=SIP Call.
c=IN IP4 204.101.104.130.
t=0 0.
m=audio 5000 RTP/AVP 0 8 18 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=silenceSupp:off - - - -.
a=fmtp:18 annexb=no.
a=fmtp:101 0-15.
a=ptime:30.
a=sendrecv.
a=oldmediaip:192.168.1.154.
a=oldmediaip:192.168.1.154.

U 2013/10/16 15:20:30.081984 204.101.1.3:5060 -> 204.101.1.8:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 204.101.1.8;branch=z9hG4bKa8db.e6beef1.0.
Via: SIP/2.0/UDP 192.168.1.154;rport=58188;received=204.101.1.3;branch=z9hG4bK456576609f1ee6272.
Record-Route: <sip:204.101.104.248;lr=on;ftag=20b49f01fa>.
From: <sip:user_z@.mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166...@mifone.ca:5060>.
Call-ID: d7fe5cafcba4b423.
CSeq: 9284 INVITE.
User-Agent: 2600hz.
Content-Length: 0.
.
U 2013/10/16 15:20:30.082890 204.101.1.3:5060 -> 204.101.1.8:5060
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 204.101.1.8;branch=z9hG4bKa8db.e6beef1.0.
Via: SIP/2.0/UDP 192.168.1.154;rport=58188;received=204.101.104.130;branch=z9hG4bK456576609f1ee6272.
From: <sip:user_z@.mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166...@mifone.ca:5060>;tag=4vK6g4vSpZD4e.
Call-ID: d7fe5cafcba4b423.
CSeq: 9284 INVITE.
User-Agent: 2600hz.
Accept: application/sdp.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE.
Supported: precondition, path, replaces.
Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer.
Proxy-Authenticate: Digest realm="mifone.ca", nonce="0df22152-3676-11e3-99ca-273c0468ce4c", algorithm=MD5, qop="auth".
Content-Length: 0.
.

U 2013/10/16 15:20:30.082953 204.101.1.8:5060 -> 204.101.1.3:5060
ACK sip:*674166...@204.101.1.3:5060 SIP/2.0.
Via: SIP/2.0/UDP 204.101.104.248;branch=z9hG4bKa8db.e6beef1.0.
From: <sip:user_z@.mifone.ca:5060>;tag=20b49f01fa.
Call-ID: d7fe5cafcba4b423.
To: <sip:*674166248187@.mifone.ca:5060>;tag=4vK6g4vSpZD4e.
CSeq: 9284 ACK.
Max-Forwards: 70.
User-Agent: Mifone Platform.
Content-Length: 0.
.

U 2013/10/16 15:20:30.083055 204.101.1.8:5060 -> 204.101.1.3:58188
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 192.168.1.154;rport=58188;received=204.101.1.3;branch=z9hG4bK456576609f1ee6272.
From: <sip:user_z@.mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166248187@.mifone.ca:5060>;tag=4vK6g4vSpZD4e.
Call-ID: d7fe5cafcba4b423.
CSeq: 9284 INVITE.
User-Agent: 2600hz.
Accept: application/sdp.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE.
Supported: precondition, path, replaces.
Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer.
Proxy-Authenticate: Digest realm=".mifone.ca", nonce="0df22152-3676-11e3-99ca-273c0468ce4c", algorithm=MD5, qop="auth".
Content-Length: 0.
.
U 2013/10/16 15:20:30.152024 204.101.1.3:58188 -> 204.101.1.8:5060
ACK sip:*674166...@mifone.ca:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.154;branch=z9hG4bK456576609f1ee6272.
Max-Forwards: 70.
From: <sip:user_z@.mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166...@mifone.ca:5060>;tag=4vK6g4vSpZD4e.
Call-ID: d7fe5cafcba4b423.
CSeq: 9284 ACK.
User-Agent: Aastra 53i/3.2.2.3077.
Content-Length: 0.
.

U 2013/10/16 15:20:30.187076 204.101.1.3:58188 -> 204.101.1.8:5060
INVITE sip:*674166...@mifone.ca:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.154;branch=z9hG4bKab44af73860d048fc.
Proxy-Authorization: Digest username="user_zdgwvg",realm=".mifone.ca",nonce="0df22152-3676-11e3-99ca-273c0468ce4c",uri="sip:*674166...@mifone.ca:5060",response="aea3341e4e6838f9a389c
Max-Forwards: 70.
From: <sip:user_z@.mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166248187@.mifone.ca:5060>.
Call-ID: d7fe5cafcba4b423.
CSeq: 9285 INVITE.
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO.
Allow-Events: talk, hold, conference, LocalModeStatus.
Contact: <sip:user_...@204.101.104.130:58188;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D204DDB>".
Supported: path, 100rel, replaces.
User-Agent: Aastra 53i/3.2.2.3077.
Content-Type: application/sdp.
Content-Length: 306.
.
v=0.
o=MxSIP 0 1 IN IP4 192.168.1.154.
s=SIP Call.
c=IN IP4 192.168.1.154.
t=0 0.
m=audio 5000 RTP/AVP 0 8 18 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=silenceSupp:off - - - -.
a=fmtp:18 annexb=no.
a=fmtp:101 0-15.
a=ptime:30.
a=sendrecv.
U 2013/10/16 15:20:30.187387 204.101.1.8:5060 -> 204.101.1.3:58188
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 192.168.1.154;branch=z9hG4bKab44af73860d048fc;rport=58188;received=204.101.1.3.
From: <sip:user_zg@.mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166...@mifone.ca:5060>.
Call-ID: d7fe5cafcba4b423.
CSeq: 9285 INVITE.
Server: Mifone Platform.
Content-Length: 0.
.

U 2013/10/16 15:20:30.187433 204.101.1.8:5060 -> 204.101.1.3:5060
INVITE sip:*674166...@204.101.1.3:5060 SIP/2.0.
Record-Route: <sip:204.101.104.248;lr=on;ftag=20b49f01fa>.
Via: SIP/2.0/UDP 204.101.104.248;branch=z9hG4bKb8db.78ed50a1.0.
Via: SIP/2.0/UDP 192.168.1.154;rport=58188;received=204.101.104.130;branch=z9hG4bKab44af73860d048fc.
Proxy-Authorization: Digest username="user_zdgwvg",realm="mifone.ca",nonce="0df22152-3676-11e3-99ca-273c0468ce4c",uri="sip:*674166...@mifone.ca:5060",response="aea3341e4e6838f9a389c
Max-Forwards: 30.
From: <sip:use...@mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166...@mifone.ca:5060>.
Call-ID: d7fe5cafcba4b423.
CSeq: 9285 INVITE.
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO.
Allow-Events: talk, hold, conference, LocalModeStatus.
Contact: <sip:user_...@204.101.104.130:58188;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D204DDB>".
Supported: path, 100rel, replaces.
User-Agent: Aastra 53i/3.2.2.3077.
Content-Type: application/sdp.
Content-Length: 366.
X-AUTH-IP: 204.101.104.130.
.
v=0.
o=MxSIP 0 1 IN IP4 204.101.104.130.
s=SIP Call.
c=IN IP4 204.101.104.130.
t=0 0.
m=audio 5000 RTP/AVP 0 8 18 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=silenceSupp:off - - - -.
a=fmtp:18 annexb=no.
a=fmtp:101 0-15.
a=ptime:30.
a=sendrecv.
a=oldmediaip:192.168.1.15

U 2013/10/16 15:20:30.188379 204.101.1.3:5060 -> 204.101.104.248:5060
SIP/2.0 100 Trying.
Via: SIP/2.20/UDP 204.101.1.8;branch=z9hG4bKb8db.78ed50a1.0.
Via: SIP/2.0/UDP 192.168.1.4;rport=58188;received=204.101.104.130;branch=z9hG4bKab44af73860d048fc.
Record-Route: <sip:204.101.104.248;lr=on;ftag=20b49f01fa>.
From: <sip:use...@mifone.ca:5060>;tag=20b49f01fa.
To: <sip:*674166...@mifone.ca:5060>.
Call-ID: d7fe5cafcba4b423.
CSeq: 9285 INVITE.
User-Agent: 2600hz.
Content-Length: 0.
 

On Wednesday, October 16, 2013 10:46:21 AM UTC-4, Darren Schreiber wrote:
Hi there,
This log is not helpful.

Please provide the full SIP traces with the actual SIP packets, along with the apps and FreeSWITCH logs

From: Fereshteh Baghaee <fereshte...@gmail.com>
Reply-To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Date: Wednesday, October 16, 2013 7:02 AM
To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Subject: Re: feature code *67 (privacy) does not work.

 9.317610 204.101.104.248 -> 204.101.104.254 SIP/SDP Request: INVITE sip:*67416...@204.101.1.5:5060, with session description

  9.318230 204.101.104.254 -> 204.101.104.248 SIP Status: 100 Trying
  9.318974 204.101.104.254 -> 204.101.104.248 SIP Status: 407 Proxy Authentication Required
  9.319196 204.101.104.248 -> 204.101.104.254 SIP Request: ACK sip:*67416...@204.101.1.5:5060

  9.448725 204.101.104.248 -> 204.101.104.254 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=7353)
  9.449413 204.101.104.254 -> 204.101.104.248 SIP Status: 100 Trying
  9.483660 204.101.104.254 -> 204.101.104.248 SIP Request: NOTIFY sip:use...@204.101.1.1:6457;transport=udp
  9.546787 204.101.104.248 -> 204.101.104.254 SIP Status: 200 OK
 10.851326 204.101.104.254 -> 74.205.223.131 SIP/SDP Request: INVITE sip:14166...@trunkingserver.com, with session description
 10.876641 74.205.223.131 -> 204.101.104.254 SIP Status: 100 trying -- your call is important to us
 10.885331 204.101.104.254 -> 204.101.104.248 SIP Request: NOTIFY sip:use...@204.101.1.1:6457;transport=udp
 10.908137 204.101.104.248 -> 204.101.104.254 SIP Status: 200 OK
 13.702136 204.101.104.248 -> 204.101.104.254 SIP Request: REGISTER sip:204.101.1.5:5060
 13.706277 204.101.104.254 -> 204.101.104.248 SIP Status: 200 OK    (1 bindings)
 13.964127 204.101.104.248 -> 204.101.104.254 SIP Request: OPTIONS sip:204.101.1.5:5060
 13.964447 204.101.104.254 -> 204.101.104.248 SIP Status: 200 OK

On Friday, October 11, 2013 10:26:48 AM UTC-4, Fereshteh Baghaee wrote:
It does not block the caller id. Checked the log, nothing is failed or something. Call was set as privacy but it pass through the caller id.
Any thought.
Thanks. 

Darren Schreiber

unread,
Oct 16, 2013, 6:21:08 PM10/16/13
to 2600h...@googlegroups.com
You appear to have included the SIP trace for the customer side equipment. I need the SIP trace for the server-side / trunk side please. You have left that out of the logs.

To make this easier, from within the FreeSWITCH CLI, please type "sofia global siptrace on". Then "/log 7". This will give you full debug.

Then run a test and include THE ENTIRE OUTPUT from start of the call to disconnect.

Fereshteh Baghaee

unread,
Oct 17, 2013, 10:38:55 AM10/17/13
to 2600h...@googlegroups.com
Hi Darren,
thanks for helping me on this.
hope that helps:

send 1445 bytes to udp/[204.101.1.8]:5060 at 14:26:08.245875:
   ------------------------------------------------------------------------
   NOTIFY sip:use...@204.101.1.3:6457;transport=udp SIP/2.0
   Via: SIP/2.0/UDP 204.101.1.4;rport;branch=z9hG4bKSU6tS8N1B8y1g
   Max-Forwards: 70
   From: <sip:use...@mifone.ca:5060>;tag=Z1iExSoDGBnD
   To: "user_u" <sip:use...@mifone.ca:5060>;tag=849c818653
   Call-ID: 6a8a68000354cc54
   CSeq: 691690720 NOTIFY
   Contact: <sip:use...@204.101.1.4:5060;transport=udp>
   User-Agent: 2600hz
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: precondition, path, replaces
   Event: dialog
   Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
   Subscription-State: active;expires=2156
   Content-Type: application/dialog-info+xml
   Content-Length: 596

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1405" state="partial" entity="sip:use...@mifone.ca">
   <dialog id="aaea57093a00ce66" direction="initiator">
   <state>confirmed</state>
   <local>
   <identity display="user_z">sip:use...@mifone.ca</identity>
   <target uri="sip:use...@mifone.ca">
   <param pname="+sip.rendering" pvalue="yes"/>
   </target>
   </local>
   <remote>
   <identity display="*674166248187">sip:*674166...@mifone.ca</identity>
   <target uri="sip:**use...@mifone.ca"/>
   </remote>
   </dialog>
   </dialog-info>
   ------------------------------------------------------------------------
recv 516 bytes from udp/[204.101.1.8]:5060 at 14:26:08.269129:
   ------------------------------------------------------------------------
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 204.101.1.4;received=204.101.1.4;rport=5060;branch=z9hG4bKSU6tS8N1B8y1g
   From: <sip:use...@mifone.ca:5060>;tag=Z1iExSoDGBnD
   To: "user_u" <sip:use...@mifone.ca:5060>;tag=849c818653
   Call-ID: 6a8a68000354cc54
   CSeq: 691690720 NOTIFY
   Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO
   Allow-Events: talk, hold, conference, LocalModeStatus
   Server: Aastra 6739i/3.2.2.3109
   Supported: path
   Content-Length: 0

   ------------------------------------------------------------------------
send 1445 bytes to udp/[204.101.1.8]:5060 at 14:26:08.346658:
   ------------------------------------------------------------------------
   NOTIFY sip:use...@204.101.1.3:6457;transport=udp SIP/2.0
   Via: SIP/2.0/UDP 204.101.1.4;rport;branch=z9hG4bKt4ZKU3648gNmc
   Max-Forwards: 70
   From: <sip:use...@mifone.ca:5060>;tag=Z1iExSoDGBnD
   To: "user_u" <sip:use...@mifone.ca:5060>;tag=849c818653
   Call-ID: 6a8a68000354cc54
   CSeq: 691690721 NOTIFY
   Contact: <sip:use...@204.101.1.4:5060;transport=udp>
   User-Agent: 2600hz
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: precondition, path, replaces
   Event: dialog
   Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
   Subscription-State: active;expires=2156
   Content-Type: application/dialog-info+xml
   Content-Length: 596

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1406" state="partial" entity="sip:use...@mifone.ca">
   <dialog id="aaea57093a00ce66" direction="initiator">
   <state>confirmed</state>
   <local>
   <identity display="user_z">sip:use...@mifone.ca</identity>
   <target uri="sip:use...@mifone.ca">
   <param pname="+sip.rendering" pvalue="yes"/>
   </target>
   </local>
   <remote>
   <identity display="*674166248187">sip:*674166...@mifone.ca</identity>
   <target uri="sip:**use...@mifone.ca"/>
   </remote>
   </dialog>
   </dialog-info>
   ------------------------------------------------------------------------
recv 516 bytes from udp/[204.101.1.8]:5060 at 14:26:08.369507:
   ------------------------------------------------------------------------
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 204.101.1.4;received=204.101.1.4;rport=5060;branch=z9hG4bKt4ZKU3648gNmc
   From: <sip:use...@mifone.ca:5060>;tag=Z1iExSoDGBnD
   To: "user_u" <sip:use...@mifone.ca:5060>;tag=849c818653
   Call-ID: 6a8a68000354cc54
   CSeq: 691690721 NOTIFY
   Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO
   Allow-Events: talk, hold, conference, LocalModeStatus
   Server: Aastra 6739i/3.2.2.3109
   Supported: path
   Content-Length: 0

   ------------------------------------------------------------------------
send 1445 bytes to udp/[204.101.1.8]:5060 at 14:26:09.748420:
   ------------------------------------------------------------------------
   NOTIFY sip:use...@204.101.1.3:6457;transport=udp SIP/2.0
   Via: SIP/2.0/UDP 204.101.1.4;rport;branch=z9hG4bKUDScXyQ85SB7Q
   Max-Forwards: 70
   From: <sip:use...@mifone.ca:5060>;tag=Z1iExSoDGBnD
   To: "user_u" <sip:use...@mifone.ca:5060>;tag=849c818653
   Call-ID: 6a8a68000354cc54
   CSeq: 691690722 NOTIFY
   Contact: <sip:use...@204.101.1.4:5060;transport=udp>
   User-Agent: 2600hz
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: precondition, path, replaces
   Event: dialog
   Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
   Subscription-State: active;expires=2155
   Content-Type: application/dialog-info+xml
   Content-Length: 596

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1407" state="partial" entity="sip:use...@mifone.ca">
   <dialog id="aaea57093a00ce66" direction="initiator">
   <state>confirmed</state>
   <local>
   <identity display="user_z">sip:use...@mifone.ca</identity>
   <target uri="sip:use...@mifone.ca">
   <param pname="+sip.rendering" pvalue="yes"/>
   </target>
   </local>
   <remote>
   <identity display="*674166248187">sip:*674166...@mifone.ca</identity>
   <target uri="sip:**use...@mifone.ca"/>
   </remote>
   </dialog>
   </dialog-info>
   ------------------------------------------------------------------------
recv 516 bytes from udp/[204.101.1.8]:5060 at 14:26:09.777261:
   ------------------------------------------------------------------------
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 204.101.1.4;received=204.101.1.4;rport=5060;branch=z9hG4bKUDScXyQ85SB7Q
   From: <sip:use...@mifone.ca:5060>;tag=Z1iExSoDGBnD
   To: "user_u" <sip:use...@mifone.ca:5060>;tag=849c818653
   Call-ID: 6a8a68000354cc54
   CSeq: 691690722 NOTIFY
   Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO
   Allow-Events: talk, hold, conference, LocalModeStatus
   Server: Aastra 6739i/3.2.2.3109
   Supported: path
   Content-Length: 0

   ------------------------------------------------------------------------
send 1445 bytes to udp/[204.101.1.8]:5060 at 14:26:10.049448:
   ------------------------------------------------------------------------
   NOTIFY sip:use...@204.101.1.3:6457;transport=udp SIP/2.0
   Via: SIP/2.0/UDP 204.101.1.4;rport;branch=z9hG4bKvpj5yS8B321SK
   Max-Forwards: 70
   From: <sip:use...@mifone.ca:5060>;tag=Z1iExSoDGBnD
   To: "user_u" <sip:use...@mifone.ca:5060>;tag=849c818653
   Call-ID: 6a8a68000354cc54
   CSeq: 691690723 NOTIFY
   Contact: <sip:use...@204.101.1.4:5060;transport=udp>
   User-Agent: 2600hz
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: precondition, path, replaces
   Event: dialog
   Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
   Subscription-State: active;expires=2154
   Content-Type: application/dialog-info+xml
   Content-Length: 596

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1408" state="partial" entity="sip:use...@mifone.ca">
   <dialog id="aaea57093a00ce66" direction="initiator">
   <state>confirmed</state>
   <local>
   <identity display="user_z">sip:use...@mifone.ca</identity>
   <target uri="sip:use...@mifone.ca">
   <param pname="+sip.rendering" pvalue="yes"/>
   </target>
   </local>
   <remote>
   <identity display="*674166248187">sip:*674166...@mifone.ca</identity>
   <target uri="sip:**use...@mifone.ca"/>
   </remote>
   </dialog>
   </dialog-info>
   ------------------------------------------------------------------------
recv 516 bytes from udp/[204.101.1.8]:5060 at 14:26:10.072220:
   ------------------------------------------------------------------------
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 204.101.1.4;received=204.101.1.4;rport=5060;branch=z9hG4bKvpj5yS8B321SK
   From: <sip:use...@mifone.ca:5060>;tag=Z1iExSoDGBnD
   To: "user_uf" <sip:use...@mifone.ca:5060>;tag=849c818653
   Call-ID: 6a8a68000354cc54
   CSeq: 691690723 NOTIFY
   Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO
   Allow-Events: talk, hold, conference, LocalModeStatus
   Server: Aastra 6739i/3.2.2.3109
   Supported: path
   Content-Length: 0


On Friday, October 11, 2013 10:26:48 AM UTC-4, Fereshteh Baghaee wrote:

Darren Schreiber

unread,
Oct 17, 2013, 11:41:20 AM10/17/13
to 2600h...@googlegroups.com
Hi Fereshteh,
Unfortunately this does not. Infact you've pasted the wrong SIP packets, ones which aren't even related to phone calls, below.

I am sort of stuck on how to help you. I know you are very eager to get this going but I am also thinking that you might want to take a step back and do a primer on SIP and VoIP first, as what you've pasted below to me is kind of a red flag that there's a knowledge gap here. I can guide you to basic debugging on Kazoo but we are now past that – this is basic VoIP and SIP. I am thinking you're going to want to learn those tools first before diving heads-first into building your own platform and debugging Kazoo.

If I am off base I am happy to take suggestions from others? But I am not sure how to help you further at this point


From: Fereshteh Baghaee <fereshte...@gmail.com>
Reply-To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Date: Thursday, October 17, 2013 7:38 AM
To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Subject: Re: feature code *67 (privacy) does not work.

--

Fereshteh Baghaee

unread,
Oct 17, 2013, 1:54:04 PM10/17/13
to 2600h...@googlegroups.com
Hi Darren,

I know what you're saying but how come it's not related, I see what I dialed there : <identity display="*674166248187">sip:*674166...@mifone.ca<
I did not get anything from those logs but thought you might find somethings out of that. 
Thanks


On Friday, October 11, 2013 10:26:48 AM UTC-4, Fereshteh Baghaee wrote:

Darren Schreiber

unread,
Oct 17, 2013, 2:12:46 PM10/17/13
to 2600h...@googlegroups.com
Hi there,
It is a NOTIFY packet. It is used for BLF. It is not related to the processing of the actual phone call.

From: Fereshteh Baghaee <fereshte...@gmail.com>
Reply-To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Date: Thursday, October 17, 2013 10:54 AM
To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Subject: Re: feature code *67 (privacy) does not work.

--

Brian Davis

unread,
Dec 19, 2013, 2:21:26 PM12/19/13
to 2600h...@googlegroups.com
I have a similar issue.  In looking at the SIP packets, the main thing I see is that Kazoo is adding the caller's phone number to the From header of the outbound INVITE.  The inbound INVITE that Kazoo is relaying did not have the phone number in the caller ID.  The SIP client we are using is not smart enough not to show the caller's phone number just because the caller's name is "Anonymous".

INVITE received from the carrier:

INVITE sip:+1617xxxyyyy@kamailioipaddress:5060 SIP/2.0 
Via: SIP/2.0/UDP carrieripaddress:5060;rport;branch=z9hG4bKf5s1pFVAgDn'iyU6cET1_GRm 
Via: SIP/2.0/UDP carrieripaddress:5060;branch=z9hG4bK02B22f94c16f303b16b 
From: "Anonymous" <sip:Anon...@Anonymous.invalid>;tag=gK02649097 
To: <sip:+1617xxxyyyy@kamailioipaddress:5060> 
Call-ID: 973213952_114748180@carrieripaddress 
CSeq: 5013 INVITE 
Max-Forwards: 69 
Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE 
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed 
Contact: "Anonymous" <sip:Anonymous@carrieripaddress:5060> 
P-Asserted-Identity: <sip:+1857xxxyyyy@carrieripaddress:5060> 
Privacy: id 
Supported: 100rel 
Content-Length: 258 
Content-Disposition: session; handling=required 
Content-Type: application/sdp 

v=0 
o=Sonus_UAC 20894 27910 IN IP4 carrieripaddress 
s=SIP Media Capabilities 
c=IN IP4 carrieripaddress 
t=0 0 
m=audio 26224 RTP/AVP 0 8 101 
a=rtpmap:0 PCMU/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:101 telephone-event/8000 
a=fmtp:101 0-15 
a=sendrecv 
a=maxptime:20 

INVITE sent to the phone:

INVITE sip:617xxxyyyy@phoneipaddress:35033 SIP/2.0 
Record-Route: <sip:kamailioipaddress;lr=on;ftag=Kapr6N5pB22cD;swsvr=202> 
Via: SIP/2.0/UDP kamailioipaddress:5060;branch=z9hG4bK71a6.666e5e96.0 
Via: SIP/2.0/UDP freeswitchipaddress:11000;rport=11000;branch=z9hG4bKgH66vU3tte82r 
From: "Anonymous" <sip:+1857xxxyyyy@freeswitchipaddress>;tag=Kapr6N5pB22cD 
To: <sip:617xxxyyyy@phoneipaddress:35033> 
Call-ID: 12027ca2-675d-11e3-a871-2f6b581f098c 
CSeq: 53320695 INVITE 
Contact: <sip:mod_sofia@freeswitchipaddress:11000> 
User-Agent: 2600hz 
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE 
Supported: precondition, path, replaces 
Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer 
Privacy: id 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: 317 
P-Asserted-Identity: "Anonymous" <sip:+1857xxxyyyy@freeswitchipaddress> 

v=0 
o=FreeSWITCH 1387288612 1387288613 IN IP4 freeswitchipaddress 
s=FreeSWITCH 
c=IN IP4 freeswitchipaddress 
t=0 0 
m=audio 24906 RTP/AVP 0 8 98 99 9 3 101 13 
a=rtpmap:98 G7221/32000 
a=fmtp:98 bitrate=48000 
a=rtpmap:99 G7221/16000 
a=fmtp:99 bitrate=32000 
a=rtpmap:101 telephone-event/8000 
a=fmtp:101 0-16 
a=ptime:20 

Darren Schreiber

unread,
Dec 19, 2013, 2:23:41 PM12/19/13
to 2600h...@googlegroups.com
There seems to be a misunderstanding about how privacy works in general.

Privacy is NOT a removal of the Caller ID Name/Number on the network side. It is a feature that sets a flag (privacy=true) to mask the Caller-ID. It is part of the Caller ID header.

The examples you list below don’t tell much – there is no use of *67. “Anonymous” is not something Kazoo is adding either I don’t think, though I’ll check on that. But the point is *67 is simply supposed to trigger the flag so that outbound carriers set the privacy bit across the network and on the last hop the receiving carrier can decide to mask the Caller ID (or not) from the consumer.

Brian Davis

unread,
Dec 19, 2013, 2:35:00 PM12/19/13
to 2600h...@googlegroups.com
My example is one where the caller is an external/non-Kazoo phone calling, via a VOIP carrier connected to a Kazoo, a phone number hosted by Kazoo and mapped to a soft phone.  The caller dialed *67 before dialing the phone number served by Kazoo, so when we receive the call, their phone number is masked, in the sense that it is not including in the From header, but it is included in the P-Asserted-Identity which I assume in this case is not meant to be used for identifying the caller to the callee, but for identifying the caller internally.  I think our job in this case is to not display the caller's phone number to the callee, the soft phone.

Darren Schreiber

unread,
Dec 19, 2013, 2:50:24 PM12/19/13
to 2600h...@googlegroups.com
I don't understand. We default to look for the P-Asserted Identity and the Remote-Party-ID. The From: is a fallback. That is how it’s supposed to work.

Are you saying you want us to use the From:? That makes no sense… Sounds like your carrier has an issue… no?

Brian Davis

unread,
Dec 19, 2013, 2:57:23 PM12/19/13
to 2600h...@googlegroups.com
Well... I was hoping you would say there is a flag somewhere I could use to force Kazoo to use the From header, instead.  Whether it's a carrier issue or not, I know it will be hard to get them to change.

Darren Schreiber

unread,
Dec 19, 2013, 2:59:27 PM12/19/13
to 2600h...@googlegroups.com
ehhhh there is not. I’ve honestly not even heard of this issue. So they just blindly mask the From: and not the Caller-ID specific header? Bizarre. Maybe I’m off base but this sounds very broken.

I will see what we can do but frankly this will probably rank pretty low priority

Darren Schreiber

unread,
Dec 19, 2013, 2:59:58 PM12/19/13
to 2600h...@googlegroups.com
Please file this on tickets.2600hz.com.

The request should be something along the lines of “Some of our carriers mask Caller-ID by changing the From: header but leaving the Caller-ID intact, instead of using the privacy bit in the Caller-ID header.

We need a flag that, on a carrier by carrier basis, allows us to use the From: header for Caller-ID and ignores the P-Asserted Identity or Remote-Party-ID header even if it’s present.

Brian Davis

unread,
Dec 19, 2013, 3:11:06 PM12/19/13
to 2600h...@googlegroups.com
Ok, thanks Darren.  I'll open a ticket.

I found http://www.ietf.org/rfc/rfc3325.txt that pretty well describes what they are doing, assuming our carrier has included us as a trusted part of the network.  It means they are telling us who is really calling, but we are supposed to look at the "Privacy" header to determine that we are not supposed to show the id.  This is my first time running into this, so it's all new to me.


--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/p1aLBNuN1yo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.

Darren Schreiber

unread,
Dec 19, 2013, 3:38:32 PM12/19/13
to 2600h...@googlegroups.com
Correct. As a carrier, we are all supposed to be sharing the real sources of the calls. That way if it’s fraud / etc. we can trace it back. (Technically there should probably be diversion headers too for SS7 compliance but that’s another ticket!)

In this case, what’s weird about your captures is that the privacy tag isn’t even there. So clearly the upstream guy isn’t setting it
Message has been deleted

Brian

unread,
Dec 19, 2013, 4:09:02 PM12/19/13
to 2600h...@googlegroups.com
I should read these things from start to finish..

The privacy: id tag is there from the carrier and kazoo passes it to the endpoint. The endpoint is either broken or not setup to use PAI for CLI info? If it was it would see the Id tag and mark the call as anonymous or so my understanding of that RFC goes.


Privacy: id 
Content-Type: application/sdp 
Content-Disposition: session 
Content-Length: 317 
P-Asserted-Identity: "Anonymous" <sip:+1857xxxyyyy@freeswitchipaddress> 

v=0


To unsubscribe from this group and all its topics, send an email to 2600hz-dev...@googlegroups.com.

Brian Davis

unread,
Dec 19, 2013, 4:20:27 PM12/19/13
to 2600h...@googlegroups.com
Ah, I think you are correct.  I see the Privacy header being sent to the phone/endpoint, so it is obviously ignoring it.  It is a pretty simplified sip client, so I suspect it is only looking at the From header.

Darren Schreiber

unread,
Dec 19, 2013, 4:21:14 PM12/19/13
to 2600h...@googlegroups.com
Most phones don’t support this. It is the carrier’s switch (ours in this case) that is supposed to screen the number. THAT is a valid bug. But I didn’t see this in the headers. Maybe I need to re-read them…

Darren Schreiber

unread,
Dec 19, 2013, 4:22:57 PM12/19/13
to 2600h...@googlegroups.com
I think this is a valid bug.

The real issue here is that Kazoo is not blocking the number from displaying on the customer’s phone / endpoint. This is different then Kazoo not setting the privacy bit, which is what I thought you were stating, or not understanding the bit from your carrier in the From: header.

OK, so this is simple. Kazoo is sending the packet to the phone as if it is a trusted endpoint. It must treat it as untrusted and screen all identifiable information. Feel free to file that, its’ valid.

Brian Davis

unread,
Dec 20, 2013, 1:21:27 PM12/20/13
to 2600h...@googlegroups.com

Darren Schreiber

unread,
Dec 20, 2013, 1:38:44 PM12/20/13
to 2600h...@googlegroups.com

Thanks.

Reply all
Reply to author
Forward
0 new messages