locked
forward call and simultaneous ring RRS feed

  • Question

  •  

    Hello All,

     

    I have the following config: 1 server acting as AD/WINS/DNS;

    1 server acting as OCS2k7 pool;

    1 server acting as OCS2k7 edge;

    2 mediation servers (one toward a no IP Alcatel PBX, the second to a CCM5.1)

    1 server acting as EXCH2k7

     

     

    Everything is working fine. We've got outbound inbound call no problem as no problem with Unified Messaging role of Exchange 2007.

     

    The only two things syill not working are the simoultaneos ring and the call forwarding....

     

     

    Any idea on the above?

    Thank you in advance for your prompt reply

    giuseppe

     

    The mediation server gives this error..

     

    TL_ERROR(TF_PROTOCOL) [0]0CC4.04F8::09/24/2007-14:58:31.887.0000027f (MediationServer,GatewayCall.GatewayParticipateComplete:1200.idx(524))( 0088D955 )$$START-MEDIATIONSERVER

    MediationCall: 54fe963cfe82488793d07505d3a1bbfb

    CallId: 09e3e562-868f-401b-a537-8cfb173433b3

    From: sip:3491827485;phone-context=unknown@ocs2k7.org;user=phone

    To: sip:0110967331@213.199.10.3;user=phone

    Direction: Outbound

    Start-Line: FailureResponseException: ResponseCode=403 ResponseText=Forbidden

    Microsoft.Rtc.Signaling.FailureResponseException: The requested operation failed.

    at Microsoft.Rtc.Signaling.SipAsyncResult.ThrowIfFailed()

    at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner, IAsyncResult asyncResult)

    at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner, IAsyncResult asyncResult, String operationId)

    at Microsoft.Rtc.Signaling.SignalingSession.EndEnter(SipInviteAsyncResultWrapper asyncWrapper)

    at Microsoft.Rtc.Signaling.SignalingSession.EndParticipate(IAsyncResult asyncResult)

    at Microsoft.RTC.MediationServerCore.GatewayCall.GatewayParticipateComplete(IAsyncResult ar)

    $$END-MEDIATIONSERVER

    Monday, September 24, 2007 1:45 PM

All replies

  • For the call forward / simultaneous ring, make sure that you are specifying a number that ocs can route. from the trace, it looks like you are trying to have it ring  0110967331, but this doesn't look like a normalized number to me. It should be trying to call something in the form of +(countrycode)-phonenumber.

     

    When you specify a number for it to ring simultaneously, it has to be a normalized number, or a number that OCS has a normalization rule for.

     

    Regards,

    Matt

     

    Thursday, September 27, 2007 7:57 PM
  • Hello Matt,

     

    no way. I tried with +39 (Italian country code) phone number but that was unsuccessful.

    The strange thing is the following one.

     

    user one logged into his communicator; simultaneous ring of his mobile number.

     

    user two logged into hs communicator.

     

    user two calls user one. User one's communicator rings along with his mobile number. User one decides to forward the call to a third number.

     

    EVERYTHING WORKS FINE!

     

    Now I change the originating number. Nolonger user two starts the action. It's a customer who is calling with his mobile user one who has the same rules described above.

    Result: neither simoultaneous ring nor forwarding capabilities.

     

    It seems that if I originate the call "externally" I lose the forwarding capabilities of communicator.

    What I see on the mediation server is

     

    sip:03491827485;phone-context=unknown@ocs2k7.org;user=phone

     

    03491827485 is the "customer's number"

    Any help on the phone-context=unknown and the rest of this mess.  Sad

     

    Thank you in advance and sorry for the contrived explanation of the problem.

    giuseppe

    Tuesday, October 2, 2007 10:44 AM
  • Hi Giuseppe,

    What phone system is handling the inbound calls from the outside? CallManager or Alcatel?

     

    If it is the cisco, then you need to check the calling search space on your voice gateway to make sure that it has the ability to make outbound calls.

     

    With a cisco system, the inbound call is "made" by the gateway to the PBX user, so the gateway has to be able to dial a 4digit extension (of course). But when a user's # is forwarded out, the originator of the call is _still_ the gateway - so it also has to have permissions to make calls out.

     

    Often times phone systems will limit the ability of external calls to be forwarded out to other external numbers. This is to avoid fraud: at 5pm, user1 forwards his phone to an overseas number. he goes home, then tells his family and friends that they can make a local call to his work # and be able to call the overseas number for free.

     

    This may not be the case for you, but since you can actually dial out from communicator, it seems most likely to be a restriction on your inbound trunk's ability to dial out.

     

     

     

    Regards,

    Matt

    Tuesday, October 2, 2007 6:07 PM
  • Hi Matt,

     

    no problem there. It is the CCM 5.0 in charge and I remember now that I did not have this problem with the beta (neither with Alcatel nor with CCM).

    I saw on other posts of a problem with phone-context.

    Someone is suggesting to add in the tel uri of the user phone-context=dialstring. Unfortunately the GUI of the user is refusing of doing so.

    I think phone-context= unknown on my incoming call is the key to understand the issue.

    Any idea in this?

     

    Thank you once again

    giuseppe

     

    Thursday, October 4, 2007 10:52 AM
  • Giuseppe,

    I have exactly the same infrastructure you have and I am ok with simultaneous ring and call forward but I have problems with audio conversation from Communicator from the Internet, I can do IM with a user on the internet but no audio !!!

     

    maybe we can get in touch off forums

     

    Ciao,

    Valerio

    Thursday, October 4, 2007 12:12 PM
  • Same problem - forward from external to external voice caller.

    After digging found out:

     

    OCS Mediation in the conditions above detects the phone number (i.e. external voice caller)

    by the precense of "+" in the first position of sip: from uri.

     

    If it's present then FROM: field on the forwarded call will be:

    FROM:<+0123456789@YourOCSSipDomain.com;user=phone>

    If "+" is NOT present

    FROM:<0123456789;phone-context=unknown@YourOCSSipDomain.com;user=phone>

     

    In my case the SIP provider gives me caller number without "+" - so I can not try the fix by "+".

     

    My gateway (Communigate Pro) rejects such a FROM: field - no forwards in such conditions.

    Can anybody try this?


     

     

    Saturday, April 19, 2008 3:01 PM
  • My guess was right: OCS needs the "+" prefix in phone number in ANY case! Not a new thing - it's clear from documentation!

     But this is right not only in the case of INVITE message & TO sip field,
    but also with FROM field!

    This is LAW & the OCS Manual is The Sacred Book!
    Simply remember this and many issues will be explained easily.

    Most probably, this is the way to force the hardware & software vendors to obey the Microsoft implementation of the protocol – very accurate in internal implementation according to RFC.

    Of course, it is also important in the case, when you need to do something with caller number - call it back, for example!

    As for me, this situation leads to some difficulties: my SIP provider refuses to give the number in the correct form (E.164).

    But, if nobody forces the world to obey standards - the standards simply don't work!

    To fix the issue with presence or absence of the "+" sign in software from other vendors you'll probably need to make double routing records (with "+" & without "+") – but in MOST cases it works only with destination, but not the source! OCS simply wants "+" and where is no way to fix it in the case of FROM field. As a result, outgoing call (for example, forward to another number in communicator) is made lake this:

    Test case:  

    Suppose you are in UK and been called from Microsoft UK office (+08706010100), but your SIP provider gives you only 08706010100.

    Most likely, Invite will be like this:

    INVITE sip: [your number]@[your gateway ip];user=phone SIP/2.0
    FROM: <sip:08706010100@[provider gateway ip or FQDN];user=phone>…

    You see in communicator 08706010100 calling, you can talk, but if you want to connect Microsoft UK & Redmond offices (+0018006427676), it most probably will fail:

    INVITE sip: +0018006427676@[your gateway ip];user=phone SIP/2.0
    FROM: <sip:08706010100;phone-context=unknown@[OCS sip domain];user=phone>;epid=...
    TO: <sip: +0018006427676@[your gateway ip];user=phone>

    The reason is simple – the call already has this FROM: field, parsed this way, when it arrives at the OCS Mediation server!

    This is not a bug, but predefined behavior to distinguish between correct and “wrong” phone URIs. Generally, if the number does not contain “+” prefix, this means it is not from the E.164 space (a local phone). For routing application it will be sometimes difficult or impossible to guess, where to route the call (if your servers are in different towns or even countries!)

    The software or hardware vendors, who want to make their products compatible with OCS, must be aware of this behavior, for example be able to rewrite From: field number (obey E.164) or parse phone-context=unknown correctly (my gateway vendor can not)...

    The Fix.

    Q. - Can this be fixed by Microsoft?
    A. -
    Yes, easily!

    For example in the Mediation Server Core:
    By design, Mediation server checks, if the given SIP URI is the correct phone number – consists only from digits, “+” and delimiters “-.,()” (ignored).
    After this check, if the first char in the number is not “+”, we could add it to the left, and process the phone number as the correct one (E.164).  

    But this behavior will let the vendors, providers & system administrators to continue using non-E.164-compatible numbers.

    And we must write all the rules for all possible local numbers given to us by our provider...

    Q. - Can someone fix this himself?
    A. -Yes and No. Yes – technically (easy), No – legally.

    Although this behavior is not good in my case, I don’t think, that OCS developers should change it.
    May be only as an option to let the users get all of the UM right now…

     

    Sunday, April 20, 2008 12:14 AM