locked
Mediation Server removing caller name - how to deactivate? RRS feed

  • Question

  • Hi

    We noted that no matter what PBX our OCS integrates with (both R1 and R2), regardless of the direction of the call, the name of the caller is never transmitted to the callee. Looking at SIP traces on all systems (we tried with CCM7 and Alcatel OXE 9.0) we see that the calling system sends the INVITE with the name, it gets to the mediation server, and the mediation server then sends out the INVITE to the other end without the name.

    E.g here's an INVITE sent from CCM7 to OCS:

    INVITE sip:9003@10.145.206.156:5060 SIP/2.0

    Date: Wed, 28 Jan 2009 18:59:43 GMT

    Call-Info: <sip:10.145.206.102:5060>;method="NOTIFY;Event=telephone-event;Duration=500"

    Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

    From: "Stephan Steiner Test" <sip:2001@10.145.206.102>;tag=f5aabbd3-b085-4088-8016-0faa1a338e64-19806985

    Allow-Events: presence, kpml

    P-Asserted-Identity: "Stephan Steiner Test" <sip:2001@10.145.206.102>

    Supported: 100rel,timer,resource-priority,replaces

    Min-SE:  1800

    Remote-Party-ID: "Stephan Steiner Test" <sip:2001@10.145.206.102>;party=calling;screen=yes;privacy=off

    Content-Length: 0

    User-Agent: Cisco-CUCM7.0

    To: <sip:9003@10.145.206.156>

    Contact: <sip:2001@10.145.206.102:5060;transport=tcp>

    Expires: 180

    Call-ID: d14aff00-9801ab1f-6ac-66ce910a@10.145.206.102

    Via: SIP/2.0/TCP 10.145.206.102:5060;branch=z9hG4bK60f5e0850e2

    CSeq: 101 INVITE

    Session-Expires:  1800

    Max-Forwards: 70

    Mediation server then sends the following INVITE to the MOC:


    TL_INFO(TF_PROTOCOL) [1]08A4.0524::02/11/2009-19:16:57.031.000023a5 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
    Instance-Id: 000031CE
    Direction: incoming;source="internal edge";destination="external edge"
    Peer: chdevocs02.nxodev.intra:5061
    Message-Type: request
    Start-Line: INVITE sip:10.145.18.51:2757;transport=tls;ms-opaque=cbe0dc6386;ms-received-cid=10D00 SIP/2.0
    From: <sip:2001;phone-context=kloten.nxodev.intra@nxodev.intra;user=phone>;epid=1BEE8B7A05;tag=3f16d3ca48
    To: <sip:9003;phone-context=kloten.nxodev.intra@nxodev.intra;user=phone>;epid=97d1257adc
    CSeq: 70 INVITE
    Call-ID: 8123f09c-6dc6-4c7d-bb50-5357508d28e5
    Record-Route: <sip:CHDEVOCS02.nxodev.intra:5061;transport=tls;opaque=state:F:Ieh.GGL_lxZO7iQaTu4kbaZdbZ17IfYpxcXqiHXUROPWwqrkHDKw2iWNWKhAAA;lr;ms-route-sig=bapEKduhMTDyitioY6ZEBsa6xqj0LDKw2iWNWKhAAA>;tag=CDAA21F59EE8392F4E3DFEF13089DB7C
    Via: SIP/2.0/TLS 10.145.201.74:5061;branch=z9hG4bK9BAD29B2.A20D2BC378A5840E;branched=TRUE
    Authentication-Info: NTLM rspauth="0100000000000000426D3EBF94929A1C", srand="76489CD3", snum="260", opaque="5694EBF2", qop="auth", targetname="CHDEVOCS02.nxodev.intra", realm="SIP Communications Service"
    Max-Forwards: 69
    Content-Length: 3836
    Via: SIP/2.0/TLS 10.145.201.75:53250;branch=z9hG4bKe321a3ab;ms-received-port=53250;ms-received-cid=7B00
    Contact: <sip:CHDEVMED02.nxodev.intra@nxodev.intra;gruu;opaque=srvr:MediationServer:a-6l7JuR_ECY0du338q6YgAA;grid=f4d455a4bc4241b9a0c053addb81a9a6>;isGateway
    Supported: replaces
    Supported: ms-safe-transfer
    Supported: gruu-10
    Supported: 100rel
    User-Agent: RTCC/3.5.0.0 MediationServer
    Content-Type: multipart/alternative; boundary=MPdoCaPKHvdcrgvjFSamvkSkT4fNGHeQ
    Allow: UPDATE
    Allow: Ack, Cancel, Bye,Invite,Refer
    P-Asserted-Identity: <sip:+41448152001@nxodev.intra;user=phone>
    History-Info: <sip:tke@nxodev.intra>;index=1
    Route: <sip:chdevedg02.nxodev.intra:49295;transport=tls;maddr=10.145.201.76;opaque=state:Ee.eaIFf5zLo0rUv26IALLTBWsAAA;lr;ms-received-cid=400>
    Message-Body: --MPdoCaPKHvdcrgvjFSamvkSkT4fNGHeQ
    Content-Type: application/sdp
    Content-Disposition: Session;handling=optional;ms-proxy-2007fallback
    v=0
    o=- 0 0 IN IP4 10.145.201.75
    s=session
    c=IN IP4 10.145.201.75
    b=CT:1000
    t=0 0
    m=audio 63729 RTP/AVP 0 8 115 13 118 97 101
    c=IN IP4 10.145.201.75
    a=rtcp:60738
    a=candidate:Rwjyx2h1u6nUEab9x7AkQAjAY8htakfa7NKBsCqBiL8 1 fV1wzFdC7j3V5zg2F+vU9w UDP 0.900 10.145.201.75 63729
    a=candidate:Rwjyx2h1u6nUEab9x7AkQAjAY8htakfa7NKBsCqBiL8 2 fV1wzFdC7j3V5zg2F+vU9w UDP 0.900 10.145.201.75 60738
    a=candidate:T2k+Pz2+QY4cLtxxaFn3OIliRHNoaXIf6/eLxplZc1o 1 uVLzbp6V9yh5qrUQ1IgIkw UDP 0.900 10.145.206.156 61075
    a=candidate:T2k+Pz2+QY4cLtxxaFn3OIliRHNoaXIf6/eLxplZc1o 2 uVLzbp6V9yh5qrUQ1IgIkw UDP 0.900 10.145.206.156 61726
    a=candidate:4vzQaIHaqHGOGwVDSudHoGJZSvQ8zHIlGSahmzyeulo 1 J/vIXyvQ9S4SPoJP0MbhAQ TCP 0.150 10.145.206.158 58447
    a=candidate:4vzQaIHaqHGOGwVDSudHoGJZSvQ8zHIlGSahmzyeulo 2 J/vIXyvQ9S4SPoJP0MbhAQ TCP 0.150 10.145.206.158 58447
    a=candidate:+8th6bpVfBTB17HOFgm6L/XNl27XT8mpvleuBQSSaZM 1 Y4qcLT8kqKSV/wyyfRrn9w UDP 0.450 10.145.206.158 56276
    a=candidate:+8th6bpVfBTB17HOFgm6L/XNl27XT8mpvleuBQSSaZM 2 Y4qcLT8kqKSV/wyyfRrn9w UDP 0.450 10.145.206.158 54971
    a=candidate:d/jYAWNb9IZMhHW//Jmo2yR9wt9+2gZ1UoGMe+yufdw 1 BljehH7VMN6vZcB0Ee2few TCP 0.250 10.145.201.75 63553
    a=candidate:d/jYAWNb9IZMhHW//Jmo2yR9wt9+2gZ1UoGMe+yufdw 2 BljehH7VMN6vZcB0Ee2few TCP 0.250 10.145.201.75 63553
    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:/cmkTala8OECMSYHxFYsLHRlzhRsgFhS3I87S5uW|2^31|1:1
    a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:+7PpXW27RD2ESxMzn1KnH3ru8n3CRmRJNOhBocd1|2^31|1:1
    a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:cKrlf6z+Npmgozk8ZCXG3oN37Xu4kmvFj08ROBsy|2^31
    a=label:main-audio
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:115 x-msrta/8000
    a=fmtp:115 bitrate=11800
    a=rtpmap:13 CN/8000
    a=rtpmap:118 CN/16000
    a=rtpmap:97 RED/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    --MPdoCaPKHvdcrgvjFSamvkSkT4fNGHeQ
    Content-Type: application/sdp
    v=0
    o=- 0 0 IN IP4 10.145.201.75
    s=session
    c=IN IP4 10.145.201.75
    b=CT:1000
    t=0 0
    m=audio 63082 RTP/AVP 0 8 115 13 118 97 101
    c=IN IP4 10.145.201.75
    a=rtcp:63157
    a=ice-ufrag:xGqG
    a=ice-pwd:vvKjkz9tifJ0FVVc3m0i0pOv
    a=candidate:1 1 UDP 2130706431 10.145.201.75 63082 typ host
    a=candidate:1 2 UDP 2130705918 10.145.201.75 63157 typ host
    a=candidate:2 1 UDP 2130705919 10.145.206.156 61758 typ host
    a=candidate:2 2 UDP 2130705406 10.145.206.156 61647 typ host
    a=candidate:3 1 tcp-pass 6555135 10.145.206.158 56194 typ relay raddr 10.145.206.158 rport 56194
    a=candidate:3 2 tcp-pass 6555134 10.145.206.158 56194 typ relay raddr 10.145.206.158 rport 56194
    a=candidate:4 1 UDP 16647679 10.145.206.158 54383 typ relay raddr 10.145.206.158 rport 54383
    a=candidate:4 2 UDP 16647678 10.145.206.158 59458 typ relay raddr 10.145.206.158 rport 59458
    a=candidate:5 1 tcp-act 7076351 10.145.206.158 56194 typ relay raddr 10.145.206.158 rport 56194
    a=candidate:5 2 tcp-act 7075838 10.145.206.158 56194 typ relay raddr 10.145.206.158 rport 56194
    a=candidate:6 1 tcp-act 1684797439 10.145.201.75 61768 typ srflx raddr 10.145.201.75 rport 61768
    a=candidate:6 2 tcp-act 1684796926 10.145.201.75 61768 typ srflx raddr 10.145.201.75 rport 61768
    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:/cmkTala8OECMSYHxFYsLHRlzhRsgFhS3I87S5uW|2^31|1:1
    a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:+7PpXW27RD2ESxMzn1KnH3ru8n3CRmRJNOhBocd1|2^31|1:1
    a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:cKrlf6z+Npmgozk8ZCXG3oN37Xu4kmvFj08ROBsy|2^31
    a=label:main-audio
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:115 x-msrta/8000
    a=fmtp:115 bitrate=11800
    a=rtpmap:13 CN/8000
    a=rtpmap:118 CN/16000
    a=rtpmap:97 RED/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    --MPdoCaPKHvdcrgvjFSamvkSkT4fNGHeQ--
    $$end_record


    As you can see, the FROM no longer contains the name of the caller, likewise for the Contact element.

    How do I get OCS/Mediation server to transmit the name in full?

    Regards
    Stephan
    Wednesday, February 11, 2009 7:24 PM

All replies

  • Hi Stephan,

    The bad news is this is a know problem with the mediation server build. The good news is MSFT know about it and have been requested by a large customer to fix it, but the more people that ask for this feature the more likely it is to happen. If you have access to MSFT engineering please make mention. There is no current work around.

    Cheers
    Chris
    Chris http://voipnorm.blogspot.com/
    • Proposed as answer by VoIPnorm Friday, February 13, 2009 3:12 PM
    Wednesday, February 11, 2009 9:51 PM
  • My colleagues installing Alcatel and Cisco PBXes are going to have a good laugh at our expense again (unfortunately they can still do that quite often.. OCS isn't quite ready to serve as a full replacement when you're used to a real PBX) as this is a standard feature there (though, while it's standard on Cisco it takes quite a bit of doing on Alcatel).

    I think we have pretty good access to MS so I'll see that we mention that this is a requirement - we have a migration of a combined Alcatel - OCS installation coming up where we're going to scrap the gateway in favor of a direct SIP interconnect and this is certainly going to come up there as well (the only reason they haven't complained yet is that there's a bug in the gateway firmware that already strips the name over the QSIG trunk).

    Cheers
    Stephan
    Wednesday, February 11, 2009 9:59 PM
  • As my friend Chris commented, this is "by design" at this point.

    The logic is that OCS is an identity based system, with strong authentication. Names in OCS are meaningful - they imply authentication. However names outside of OCS are in clear and can be easily spoofed.

    For outgoing calls, the notion was to confine names to strongly authenticated realms only, or to leave it to the third party system to make its own determination of whether it wanted to perform name resolution, against what and how. Third party systems generally have some reverse number lookup capability and should be able to present caller name if they deem it appropriate. Note that transmitting the name from system to system is not mandated by the standards.
    For incoming calls there is the possibility to do number lookup against Outlook contacts in particular and to present names on that basis.

    Several concern have appeared over time with respect to this approach. For example, some third party systems such as CUCM are unable to do reverse number lookup for incoming outside calls (so it's not just an OCS problem, of course ;). Also it is unclear that it is any less easy to spoof the calling party number than the calling party name, so the argument on spoofing would eventually lead to presenting no information at all on incoming calls unless they are strongly authenticated. And that is clearly not an option... Last, OCS R2 now provides more situations where non authenticated names can be presented (such as non authenticated users joining an audio conference from a web browser) - and OC is now able to indicate that the user is not authenticated through a graphical indication.

    We are clearly aware that customers would want the names to be transmitted across Mediation Server, and giving it due consideration for the future.

    Thanks

    Wednesday, February 11, 2009 10:40 PM
  • Stephan,

    It is easy to criticize, but in 5 years, Microsoft has released LCS 2003, LCS 2005, LCS 2005 SP1, OCS 2007 and OCS 2007 R2. Each big time versions with very significant improvements and a very significant feature scope increase toward enabling our customers to progressively remove their PBX. Show me anything remotely close from any major vendor in the space...

    So not everything is right yet. Let's not throw the baby out with the bath water. I kind of resent the negativity of the comment on "OCS isn't quite ready" on the face of one feature that is sure important but not core to the functionality of the system. Instead, let's look at the curve OCS is on, and I think everybody will agree that curve is steeper than anyone else out there. Based on what feature you look at, you may decide that the point on the curve today is below or at the same level or above PBX "x", but the point is, it's like a formula 1 car racing a Ford Fiesta, if it is not ahead yet it will be before you know it. If it's your money, are you ready to buy a traditional PBX system today will all the phones, etc that come with it, and stick with it for the next 10 years of so? Clearly this choice will be an albatros before you know it...

    You say it is a standard feature on CUCM. It's not quite that simple. CUCM does not out of the box perform reverse number lookup on an outside incoming call even from another voice system within the same enterprise (and that is part of the problem here). However if it receives in the information in the "right" format it will display it. While OCS does not do that today, it can actually do more in at several aspects - it can do reverse number lookup for incoming outside calls out of the box as long as the calling number is an enterprise number (in active directory) even if that number and user are not on OCS. It presents fully authenticated name for federated calls. It is capable of reverse number lookup against Outlook address book for outside numbers. And the good news is that OCS can handle the name - it's just that that name is stripped at the mediation server at this point in time. Customer will of course complain, and to some it will be a big deal (it has not yet been blocking at any customer I am aware of) but nothing big is broken... so let's keep it positive and look at the big picture ;)

    I'd like to rebound on another point you make. I am not aware of any Direct SIP possibility between OCS and Alcatel (and I can tell you I have looked into this a lot). Last I tested it was broken due to what I consider non compliance issues on the Alcatel side. I also believe there is no supported Direct SIP implementation between CUCM and Alcatel today... I'd be curious if you can give us a bit more information on what you are doing (especially if it works ;)

    Cheers

    Wednesday, February 11, 2009 11:10 PM
  • Do you know any regular PBX that does reverse number lookup? I'm not sure about the Ascotel (now Aastra something) that we had prior to SIP at home but I think it used speeddials. I know Alcatel uses Speeddials for that so it's not really a reverse number lookup.. it's kinda cheating since you need to enter every number into the phonebook and cannot have it on a centralized directory (to make this more fun you can actually query an LDAP directory when you query the phone book. but it's a rollover so it queries the internal phonebook first and only then the external directory). CCM, as you mentioned, has nothing though we make good money selling custom directories and lookup applications (which I write).

    With SIPs inheritent ability to transmit the name, it seems very counterintuitive to remove the name - after all transmitting the name has already been possible in the old telephony world over QSIG - we have many interconnects in place that way where we transmit numbers between an existing PBX the customer has, and our Cisco or Alcatel installations. Not having the name almost always leads to a blocking point in the acceptance tests. Just think about it.. somebody sends you the name, you discard it, then you look up the number again? Most people would scratch their heads.. and as you pointed out, you can spoof numbers as well. It takes me about 20 seconds and I can send you any number I want.. and that's not using SIP.. that's using the traditional PSTN network where such things are generally less easy to achieve. You argue reverse number lookup.. that's all good and well but how many customers really have all phone numbers in AD and maintain them? We also do user provisioning (I have one project right now where AD is the source) and I have yet to talk to a customer that really has everything in AD and up-to-date. The project I'm working on right now will require that the customer really starts maintaining that information. The best situation I've come across so far is if there's a meta directory in place.. but it generally that just means the might have the phone number somewhere and could store them in AD but they don't. OCS makes this more of a necessity and thus give me another point to sell a provisioning solution so the customer doesn't have to maintain the numbers manually.

    I think we should take each system for its unique strengths but not forget about its weaknesses, then look at the customer and see what fits their needs best. There are customers where OCS approach to communication is a good fit, and it can do things you couldn't do just a few years ago with any other system, and where even today you need a lot of add-on systems (though you could argue that setting up all the roles in OCS means many systems, too.. my OCS R2 deployment involves 8 servers and that's without any redundancy. I do things with my MOC you don't do with our house PBX (Alcatel) and that with Cisco would require that I install both a server for meeting and presence for features out of the box of a standard OCS server. But then again, I can do a lot with the traditional systems you cannot do with OCS.. I don't think you need to get defensive about that, it's just the way it is and it's only natural that people working with another product will snicker when you can't do something and you can snicker when they can't do something.. as long as it remains amicable (we have all the voice people together and it's really a friendly competition and we have a bunch of people that even work on two systems) I see nothing wrong with that.

    If I recall correctly, we've been doing H.323 trunks between Alcatel R6 to CCM 4 and above since 04 - my lab systems never had a traditional trunk. Last year, due to a network upgrade, we suddenly had audio issues and decided to go SIP (Alcatel R8.0 at that time).. and we had one way name display at that time (Alcatel -> Cisco was OK).. at the time we left it at that (our bosses don't like us playing with internal systems when we're supposed to log billable hours) but it was definitely Alcatel's fault. Since the upgrade to R9 at the end of last year caller name display is fine for both sides now. Also, there's no media proxying between the two (never has been as far as I can recall unless you force it) since Alcatel removed the forced media proxying for their own phones (I believe in an R6.x release) - I just verified with Wireshark to be sure.


    Thursday, February 12, 2009 11:05 AM
  • Check out the NET gateway (VX1200 or VX1800) - disclaimer: i represent NET in Australia.
    We've integrated CCM (using SIP) and Alcatel OXE (using SIP and QSIG) with OCS and Exchange UM.

    The calling name is an interesting discussion.
    As stated, inbound to OCS, there is no way currently to have OCS display a name it receives from the gateway. However, this isn't really needed as long as the RNL works (i.e. calling numbers are presented correctly to OCS).

    Interestingly enough though, my colleagues in France have been able to get Calling Name to work the other way. That is, when an OCS extension calls an Alcatel extension, the VX (thru its AD Integration capabilities) is able to retrieve the user's name, and populate the name in the signaling to the Alcatel (SIP and/or QSIG). So Alcatel user's not only receive the OCS's extension number displayed on the phones, but their name also.


    MF

    Thursday, February 12, 2009 11:15 AM
  • Hi Waverider,

    This is an interesting way to provide outbound name resolution but its not what I would call an effective work around for most enterprizes seeing as a particular gateway is required. The really solution lies around RNL versus caller name passing through the mediation. Using something freely available that allows identification of a caller when RNL is not available is something that certainly needs to be looked at and is a nice feature enhancement that OCS could take advantage of.

    I think the discussion around name resolution versus caller name is an interesting one that certainly brings forward a number of good points as both Stephen and Francois have raised. Although Microsoft have certainly been looking toward being a replacement for the PBX there is a way to go and removing things that have been done in the past sometimes works and sometimes not. Its the art of picking the right features from a pbx to carry forward and which ones to leave behind. Native MWI in Exchange Unified messaging is another example of this. Customers play a big part in this so letting Microsoft know what you consider important to carry forward from traditional PBXs is an important area because they are listening.

    Cheers
    Chris 
    Chris http://voipnorm.blogspot.com/
    Thursday, February 12, 2009 4:25 PM
  • Hi Stephan, I do agree with essentially most of your points, and did not mean to sound defensive - sorry.

    I agree there a still things traditional systems can do that OCS does not. In my view, features fall in several categories:

    - Stuff that is very specific to the way the traditional systems work and that don't need to be recreated in a modern system (even though many customers will still put them in the RFP out of habit); there can be a large number of those...

    - The bread and butter basic features, i.e. the traditional individual features that everybody uses, such as spearkerphone, mute, hold, forwarding, voice mail, direct and consultative transfer, ad hoc 3 party conferencing, etc). There are not that many of those feature - probably less than 20 in practice. The interesting thing is that most of us used to have access to those features but did not know how to use them on traditional system, whereas OCS makes them very intuitive and easy, so their usage actually can increase. OCS 2007 (aka R1) essentially aready intended to provide most/all of those, and any gap remaining such as the CLID/calling party name should be filled over time. We appreciate your pointing out of those gaps.

    - Advanced features that are typically only used by subsets of users but are required to be fully substitutive, such as some team and boss/admin features, some ACD and IVR based features, various modes of call parking and pickup, etc. Those features were not in scope for OCS 2007, but become in scope starting with R2 where a lot of those features are introduced (in many cases in innovative manners than make them more powerful than in the traditional implementation), and full equivalence at this level is targetted for the next major release.

    - Stuff that is rarely used on traditional systems (or by very small number of users - sometimes it's even a feature that was created for just one customer); that is one of the reasons there are hundreds of features when one looks at all the PBX out there... OCS is not likely to incorporate any of those features. That is where having an open API platform is really useful, because it makes it possible for ISV to create those features if customers really want them enough to pay for that development

    - Specialized features such as contact center, etc. Those are at this point provided by partners whose offer is deeply integrated with OCS.

    - Features that only OCS can provide, with presence, multimedia, integration with Active Directory, integration into business applications, etc. That is the real value - there is only limited value in replicating (once more) traditional features on a different platform, whereas the value is in enabling better modes of working, collaborating and communicating. And that is where OCS is unique. When it comes to investing resources (which are always scarce) it often makes more sense to create those new capabilities than in replicating old features...

    I hope this makes sense!

    Saturday, February 14, 2009 8:53 PM
  •  @Fdoremieux (is that F for François or Fréderic by any chance?)

    I guess we could go on for ages but it is an interesting subject in general. Just today we had a little friendly competitive exchange with some of our Alcatel consultants over lunch and one of the point they raised I hadn't even considered before:

    You said, features that only OCS can provide. Take presence.. both Cisco and Alcatel actually beat you at your own game there (depending on the manufacturer only in some ways). They can offer phone based presence.. meaning your phone state is taken into account not from the time a call is answered, but from the time you go off hook. it stands to reason that some time in between you going off hoook (Tanjay) or the INVITE being sent (MOC) your would prefer not to be disturbed by the phone anymore. With OCS, my status only changes once the call has been answered.. so I might be one ring away from being connected to an important customer and then somebody calls me.. isn't enhanced presence supposed to prevent that from happening and let people know that they shouldn't call me just then (but could still IM me)?
    And speaking of Presence, while I haven't managed to set it up in the lab yet, Cisco's presence solution also integrates with Exchange and thus can change presence based on your calendar, just like OCS.
    Or let's talk multimedia.. both manufacturers also support ad-hoc adding of audio and video to an IM session. As far as video goes I know Cisco does multipart video also - not sure if you need dedicated hardware - Alcatel is still working on that.
    With the proper server role you can also do live meeting style meetings over the web with audio and file exchange - they both supported audio for external participants prior to R2 :)

    And as far as integration into business applications goes.. that's right up my domain and I can do that for pretty much any PBX. At times it might involve an additional server or even additional manufacturer, but CTI has been around for ages (and MS set the bar with TAPI though nowadays it's not always the favored solution for integration for various reasons). Granted, the integration on a server level (run your own apps in the core process) is better and shows many others where you need to go - though by my (admittedly limited) knowledge of other competitors, there's a bunch of them that offer great potential in that area too (e.g. take FreePBX.. features basically are scripts you can write in a bunch of languages.. ). Although I give you that at the core, OCS probably allows for integration at a level that the others cannot approach (and won't be able to approach without making major architectural changes)..

    Also, I was thinking about the whole name thing again while driving home from work this evening.. we do have a bunch of customers that have private interconnects to each other. It might be companies sitting on the same PBX, or companies that are in the same building and figured why not call each other if they have business with each other - or organisations that have a relationshiop between each other. Today, they have the names without having to know about the other side's organization at all. Can't do that with reverse number lookup. And you cannot expect that everybody migrate to OCS at the same time (I'd try to get one to bite, then use them to help sell the solution to others) and the though goes if they can't do a basic feature my skype client at home does.. what else am I missing out on and nobody wants to tell me about. And as nice as federation is, we have plenty of customers where going over the Internet is simply a big nono. Private interconnects over those leased lines are already a big step, but connecting their data network or god forbid connecting something to the Internet? And I can't really blame them even when they're overreacting.

    Next month there's anthother instance of CeBit and another chance for me to learn more about the competing system I know too little about (Avaya, Siemens, Nortel, Aastra).. hopefully I manage to find some knowledgeable people at the stands to have some fruitful discission about features. last year was all about single number reach so I'm assuming they have that working now so the whole UC/presence/multimedia thing sounds worth exploring.

    P.S. Of course you remember all those RFP/RFQs written by consultants targetting a specific system and asking about all those pesky things you know almost nobody can and almost nobody will ever use - and if they just count the nos and compare the final number you're off to a bad start. Hopefully, as the number of project grows we become more familiar with writing the missing features ourselves - something which works quite well for the Cisco platform now (Alcatel has a lot more features so there's less potential for something like that..). Being able to demo a feature your competition has down for a no always help :)

    • Proposed as answer by Robert Gibson Wednesday, May 27, 2009 7:11 PM
    Tuesday, February 17, 2009 10:23 PM
  • Given so many telecom vendors do permit the transmission of caller name, that this is not selection on the Mediation Server, an option,  is not the MS I have known for many years.   I have had several very large financials visit our center in the past year, all wanting external caller ID by name, their immediate concern was customer service not security as security is far more than just caller name alone.  For these reasons I must dismiss the security argument as a mere excuse for an incomplete product that does measure up to the industry norm.

    Wednesday, May 27, 2009 7:24 PM
  • I'd recommend Microsoft let the customer decide if they want to pass caller name rather than assume they know what's best.  Make the capability available and you will be one step closer to actually having customers consider using OCS as a PBX replacement. 

    Wednesday, May 27, 2009 7:28 PM
  • So there is a fix on the way for this issue from Microsoft. I can't give a date but it has been confirmed that it is on its way for R2 in the near future.

    Cheers
    Chris
    http://voipnorm.blogspot.com/
    Thursday, May 28, 2009 2:08 AM
  • This issue is now resolved with July rollup patches for OCS R2. The front end and mediation servers require patching. Please read the link to find out configuration changes required on the mediation server:

    http://support.microsoft.com/default.aspx/kb/972721/EN-US





    http://voipnorm.blogspot.com/
    Tuesday, August 4, 2009 5:28 PM