[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] User Privacy during  Early Media
From:       "Nataraju A B" <bnataraju () kodiaknetworks ! com>
Date:       2006-05-24 6:51:14
Message-ID: 000a01c67efc$c681ede0$4203a8c0 () Nataraju
[Download RAW message or body]

Comments inline...

-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Sumin Seo
Sent: Thursday, April 20, 2006 1:52 AM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] User Privacy during Early Media


HI all,
 
I have a question for you about user privacy issue during early media

When I call to IVR systems, some of IVR systems send IVR voice during
early media.

Of course, we can only send DTMF during early media, but as you know,
some of IVR systems use a voice recognition system.  So, if UAC gets
"a=sendrecv" in SDP, it should prepare bidirectional media channel.

If UAC opens a RTP send/recv channel before call connected(200 OK)  and
user doesn't know that their voice sends to other side during early
media, it can intrude on user's privacy. 

[ABN] I don't think so... This might happen for connected call also...
UAS can always send the media back to UAC soon after the INVITE is
received if UAC carried SDP with RTP port opened as recvonly/sendrecv.

I remember one episode of TV series - Monk.

Somebody made a call to air flight agency and before connected to
representative, he heard IVR voice.

But he didn't know that his voice sent to other side. Unfortunately One
of agency representative heard what he was talking for QOS. This
invasion of privacy led to murder .

As you know, if we change a calling state GUI to connected state GUI
just after getting 18X provisional message to let user know that their
voice sends to other side, It will cause more problem.  Just warning
message is enough?

Is there any spec or articles about this kind of privacy issue during
early media?

[ABN] I guess, there is no need of a separate RFC for this purpose
alone... 
 
 
Thanks in advance for your help. 

 

Sumin.

 

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


[prev in list] [next in list] [prev in thread] [next in thread]