Presence and IntComm WG

[Steve Blair <>]

Joe:

  See comments below.

-Steve

Rork, Joseph (J.P.) wrote:

> <soapbox>
> I am a Vonage user.  One of the things that I think is cool is the 
> click-to-call feature.  I just highlight a bit of numeric text on my 
> computer, push F6, and my analog desk phone rings, connecting me to 
> the phone number that I highlighted.  Simple, stupid, cool.  Easier to 
> use then Skype.
We had this with Broadsoft as well. For a production service it is cool 
and also integrates
billing into one statement. No one need bring in their bill for 
reimbursement. The MM crowd
may not be WOWed by integrated billing but it wouldn't hurt to mention 
that benefit of
click-to-cell (call).

> Great, what does this have to do with PIC?
I dunno. What ?

> I realize that our group promotes SIP as our protocol of choice, and 
> that we wish to promote presence and integrated communications using 
> SIP.  However, I also thing that we can achieve our goal without 
> demanding that we are SIP end-to-end.  SIP.edu, which actually likes 
> SIP so much that it has SIP in it's name, isn't always SIP 
> end-to-end.  But people get the idea.  I use SIP, I contact someone. I 
> argue that we relax our grip on controlling all aspects of the RTC, 
> and focus more on the PIC.  All the end user wants to do is 
> communicate with someone; we want to show them how to use PIC to 
> communicate with that someone more effectively.
To me the message in the last paragraph is that user driven 
functionality is important. I see
this as a follow-on to what Jeremy & I were talking about in the 
conference call. I believe we
need to offer a baseline set of features at each demo. We can add to or 
even select from a
set of features based upon demo requirements. click-to-cell is fun and 
can be useful. For the demo
however I'd like to see us be able to explain why we are adding this 
functionality to a
Presence and Integrated Communications demo. I think we have the basis 
of that explanation
in your original message.

> I propose that we allow the conference attendees to add their existing 
> cell phones to their profile at the conference, mimicking what a real 
> world implementation might look like today.  Then, as part of our 
> integrated communications package, we offer this as a voice endpoint 
> using the SIP-to-PSTN gateway we plan on providing.  It will allow he 
> end user to make softphone to cell and cell to cell calls, depending 
> on how we implement it.
Lets take it even further. Lets conduct this demo by using resources on 
PSTN gateways where the
resources are donated by participating members for the MM only. I 
envision the idea being
implemented as follows. Attendees can opt-in to registering their cell 
phone number. This number will
be known to the proxy but need not be advertised to humans.

When the owner of the originating cell phone wishes to click-to-cell, an 
SER to owner-cell-phone
call is originated via a participating gateway that is in the same local 
calling area as the cell phone
number. This avoids the long distance charges on the gateway provider. 
The IP call leg to the called
party is completed as usual.

> We can take it one step further and allow people to not only register 
> their cell phone number, but also their SMS contact as well.
Sorry I don't do SMS.

> Scenario 1:  Tarzan wants to call Jane.  Tarzan is using a SIP 
> softphone on his computer and puts in .  The system 
> sees that Jane is registered at softphone  and rings her 
> softphone.  Done already today.
>
> Scenario 2:  Same as one, but Jane's battery on her laptop died and 
> she isn't registered at all.  System recognizes this, and redirects 
> the call to the cell phone that Jane provided in her profile out the 
> PSTN gateway.  Note Tarzan still doesn't know Jane's cell, just her 
> unique identifier.
>
> Scenario 3:  Tarzan still wants to call Jane, but Jane is sitting in a 
> coconut opening seminar, and doesn't want to be disturbed by phone 
> calls.  The system recognizes that Jane has set Jane has set her "DND 
> by voice" flag, and offers Tarzan the option to IM her.  Tarzan 
> decides no, but instructs the system to have Jane call him when both 
> of them are not seen as busy by voice. 
>
> Scenario 4:  Tarzan in hurry, doesn't have time to boot up old 386, 
> runs to kiosk, logs in as Tarzan, tells system to call Jane using 
> Tarzan's cell phone.  Tarzan's cell phone rings, Jane answers either 
> cell phone or softphone, depending on which she is using at the time.
What about Chim Chim. Oops sorry wrong show. :-)

> I know that there are some that are not fans of gateways, but we are 
> putting in a PSTN gateway because we recognize the need to expand our 
> calling audience.  It would be beneficial if we use that same gateway 
> to extend the integrated part of our communications.  I believe that 
> it would help people 'get' what we are trying to explain.  And it 
> would also help solve that little nagging voice problem that we admit 
> to having...

  Perhaps. I think we need to be careful that we don't send the message 
that we are the same as the
voip-wg. We are suppose to be about more than voice calls. Plus with 
voice working as poorly
as it has at past MMs I am not sure I want just voice in any form as the 
newest PIC feature.

  If we must emphasize voice then lets look at call quality using 
different codecs. I think there is more
value in better quality using less bandwidth then just call completion.

  I have no problem adding gateways but I think either Ford will have 
to host it or we need
support from the community. Otherwise I think we need to line up a 
sponsor to pay for the
gateway service. Did anyone see Bruce from Avaya? (Just kidding Bruce). 
If you use Cisco
boxes for the gateway I'd be happy to help with the config where possible.

  Hey I like the view from this soapbox...

-Steve

> </soapbox>
>
> Regards,
> Joseph Rork
> Associate Architect
> Next Generation Collaborative Computing, SIE
> Ford Motor Company
> Phone: 313-594-6672
> Email: 
>
> "There are 10 types of people in the world: Those who understand 
> binary, and those who don't."