locked
Call Forward and Simulatneous ring errors RRS feed

  • Question

  • Hello all,

     

    We have recently run into a problem with some users who want to forward thier calls to thier cell phones.  They are able to set up the rule, but the call does not get forwarded to the cell phone, it goes to voice mail.  The same thing happens if simutaneous ringing is setup with the same cell number, the cell phone does not ring.  Apparently this is sporadic and forwarding does work sometimes, but not others.

     

    They also had a problem with the 'call forward icon' disappearing in the moc.  It re-appeared after disabling the enterprise voice setting and then re-enabling it.

     

    any thoughts?

     

    Thanks.

    Friday, September 19, 2008 1:43 PM

All replies

  • Hi,

     

    Is this an integration with a PBX or are you connecting to a PSTN gateway?

     

    Cheers

    Chris

     

    Friday, September 19, 2008 5:45 PM
  • It is an integration with a PBX. 

    Friday, September 19, 2008 7:49 PM
  • Depending on your PBX (Nortel and Cisco UCM are examples) it may or may not accept SIP 183 without SDP information which OCS uses. If it does not then what you describe can happen. If this is the case you will need to talk with MSFT to get a fix that is available that will send a fake 180 ringing message to enable the call to stay up and for the cell phone to ring. The issue with the 183 message being dropped is that the PBX will timeout the call because it has not seen a response from OCS that it will accept. Depending on where the call comes from ei PSTN or on the PBX itsefl the call may or may not work and for SIM ring the function will work if the person is logged on but when they log off it will have a similar problem you descirbe. If this is not your issue you will have to enable logging on your mediation server to see the traffic coming from your PBX to narrow down the issue.

     

    Hope this helps

     

    Cheers

    Chris

    Monday, September 22, 2008 12:09 AM
  • Hi,

    A couple questions:

    1) when the call fails to forward, you mentioned that it goes to voice mail. Does it go to cell VM or Exchange VM?

    2) do you have the "only apply during business hours" option checked in the call forwarding page? if yes, this could explain the sometimes it works / sometimes it doesn't

    3) really dumb question here, but: the users aren't testing this by using their cell phone to try to call the work number? The first time I set up simultaneous ring, I tested it by calling my work# with my cell. Of course it went right to my cell VM because... I was on my cell! So it's worth checking to see if this is the case as well.

     

    Regards,

    Matt

     

     

    Wednesday, September 24, 2008 3:36 AM
  • 1)  It goes to Exchange VM

    2)  No, that option is actually grayed out, it cannot be checked.

    3)  nope!  Smile

     

    Wednesday, September 24, 2008 12:44 PM
  • Hi Matt and 007,

     

    Number three is a good one. I have done that to when I am not thinking.

     

    I think the best way for you to find out what is going on is to turn logging on at the mediation server using OCS. This will give you a good idea of the traffic going in an out during the sim ring setup and teardown. Use OCS for the logging rather than a packet capture tool as it will show you the SIP traffic in a easier to read format. Ethereal and others are good tools but OCS has a good logging interface you should get to know well if you dont already.

     

    Cheers

    Chris

    Thursday, September 25, 2008 4:11 AM
  • Did you actually manage to get this fixed?  I'm running into a similar problem with call forwarding, except in my case forwarding never works, and I'm just trying to forward between communicator users at the moment.  The SIP trace looks like it's rejected with an Invorect Via header, and if I dig into the log, it looks like the rejection message is that there's an incorrect number of via headers (for some reason, there are two of them).  I've added a snippet from the OCS log below.  The call ends up going straight to exchange UM.  Any ideas?

    TL_INFO(TF_COMPONENT) [0]0E5C.1220::01/09/2009-14:36:47.478.000b328a (SIPStack,CRecvContext::ProcessCompletion:974.idx(155))( 01140F58 ) Received 3134 bytes
    TL_INFO(TF_PROTOCOL) [0]0E5C.1220::01/09/2009-14:36:47.478.000b335d (SIPStack,SIPAdminLog::TraceProtocolRecord:1224.idx(122))$$begin_record
    Instance-Id: 000003A5
    Direction: incoming
    Peer: 192.168.201.21:3967
    Message-Type: request
    Start-Line: INVITE sip:homer@rnddev.computer-talk.com:5063;transport=Tls;maddr=RNDOCS2007.rnddev.computer-talk.com SIP/2.0
    From: "Marge Simpson"<sip:marge@rnddev.computer-talk.com>;tag=8db2663f85;epid=6aa49c0c05
    To: <sip:bart@rnddev.computer-talk.com>
    CSeq: 1 INVITE
    Call-ID: e0a943e5ab374ce392ceb3da890f2d47
    ms-user-data: ms-publiccloud=false;ms-federation=false
    Record-Route: <sip:RNDOCS2007.rnddev.computer-talk.com:5061;transport=tls;ms-role-rs-to;lr>;tag=8CCA366455262A10B8CBE4939A5A1F2E
    Via: SIP/2.0/TLS 192.168.201.21:3967;branch=z9hG4bKE92A3FAE.C9DBB147;branched=TRUE
    Max-Forwards: 10
    ms-application-via: backend_token;ms-server=RNDOCS2007.rnddev.computer-talk.com;ms-pool=RNDOCS2007.rnddev.computer-talk.com;ms-application=AB072FF0-C918-424c-AC12-7C100E91FE3E
    Content-Length: 1078
    Via: SIP/2.0/TCP 192.168.201.21:3960;ms-received-port=3960;ms-received-cid=2D00
    P-Asserted-Identity: "Marge Simpson"<sip:marge@rnddev.computer-talk.com>,<tel:+1001>
    Contact: <sip:marge@rnddev.computer-talk.com;opaque=user:epid:EZC5-dFxilGhENTnoO51fwAA;gruu>
    User-Agent: UCCP/2.0.6362.111 OC/2.0.6362.111 (Microsoft Office Communicator)
    Ms-Conversation-ID: AclyZ7NiFTJ7pHxPT6ugpPlbWuV7Jg==
    Supported: timer
    Supported: ms-sender
    Supported: ms-early-media
    Supported: Replaces
    ms-keep-alive: UAC;hop-hop=yes
    Supported: ms-conf-invite
    Content-Type: application/sdp
    Referred-By: <sip:bart@rnddev.computer-talk.com>;ms-identity="MIIBTAYJKoZIhvcNAQcCoIIBPTCCATkCAQExDzANBgkqhkiG9w0BAQUFADALBgkqhkiG9w0BBwExggEUMIIBEAIBATBqMFwxEzARBgoJkiaJk_IsZAEZFgNjb20xHTAbBgoJkiaJk_IsZAEZFg1jb21wdXRlci10YWxrMRYwFAYKCZImiZPyLGQBGRYGcm5kZGV2MQ4wDAYDVQQDEwVybmRDQQIKGrjJlgAAAAAAAjANBgkqhkiG9w0BAQUFADANBgkqhkiG9w0BAQEFAASBgF7MtSBYJn_DbCHEwoOF9jV0xLKhH7vcHv76La9i-GSwCg-Wc8A3w5mHrffwvGswF9oTGJT7ZgDioG4Rq9ZhWDF708VuWjFvUN5kDvuUDQKlgDBE6KOtW5CErPi_NxT06pkaPcNJaqyi4WrwXi12Skh25ChV7yurDaLeLg6jIOdq:Fri, 09 Jan 2009 14:36:47 GMT";ms-identity-info="sip:RNDOCS2007.rnddev.computer-talk.com:5061;transport=tls";ms-identity-alg=rsa-sha1
    Ms-Target-Class: Primary
    Message-Body: v=0
    o=- 0 0 IN IP4 192.168.201.21
    s=session
    c=IN IP4 192.168.201.21
    b=CT:99980
    t=0 0
    m=audio 6628 RTP/AVP 114 111 112 115 116 4 8 0 97 101
    k=base64:eNOiTaqtZNVyat7Y9tupiqPuFpFr7aFG0jkFWige+nCB8AZvC4O57NqQ44+T
    a=candidate:um25weahJ+wlu/xbXUk/Ppu8UU3SL8YQl2YuR0mfv1w 1 nmfg5dsaVQS345RDUDjx/w UDP 0.890 192.168.201.21 6628
    a=candidate:um25weahJ+wlu/xbXUk/Ppu8UU3SL8YQl2YuR0mfv1w 2 nmfg5dsaVQS345RDUDjx/w UDP 0.890 192.168.201.21 19342
    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:AU2FSE9RRGI1VnIjOWdejPJvGFnH6LOS0rtbuwBd|2^31|1:1
    a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:zRBqwuZRpY4AkdzcFJjE8bCo1yxGHnA9AowGRJJ0|2^31|1:1
    a=maxptime:200
    a=rtcp:19342
    a=rtpmap:114 x-msrta/16000
    a=fmtp:114 bitrate=29000
    a=rtpmap:111 SIREN/16000
    a=fmtp:111 bitrate=16000
    a=rtpmap:112 G7221/16000
    a=fmtp:112 bitrate=24000
    a=rtpmap:115 x-msrta/8000
    a=fmtp:115 bitrate=11800
    a=rtpmap:116 AAL2-G726-32/8000
    a=rtpmap:4 G723/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:0 PCMU/8000
    a=rtpmap:97 RED/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=encryption:required
    $$end_record

    TL_INFO(TF_COMPONENT) [0]0E5C.1220::01/09/2009-14:36:47.478.000b33eb (SIPStack,CSIPRequest::ProcessIncomingRequestUri:311.idx(5656))( 02BA5AE8 ) Matched maddr with incoming connection
    TL_ERROR(TF_COMPONENT) [0]0E5C.1220::01/09/2009-14:36:47.478.000b3440 (SIPStack,CSIPRequest::_EnsureValidNumberOfViaHeaders:311.idx(1615))( 02BA5AE8 ) Exit - unexpected number of via entries for a non-server connection. Returned 0xC3E93F04(SIPPROXY_E_REQUEST_NO_CORRECT_VIA)
    TL_ERROR(TF_COMPONENT) [0]0E5C.1220::01/09/2009-14:36:47.478.000b3441 (SIPStack,CSIPRequest::ProcessVia:311.idx(891))( 02BA5AE8 ) Exit - incorrect number of via headers. Returned 0xC3E93F04(SIPPROXY_E_REQUEST_NO_CORRECT_VIA)
    TL_ERROR(TF_COMPONENT) [0]0E5C.1220::01/09/2009-14:36:47.478.000b3442 (SIPStack,CSIPRequest::ValidateInboundHeaders:311.idx(1469))( 02BA5AE8 ) Exit - failed to ProcessVia(). Returned 0xC3E93F04(SIPPROXY_E_REQUEST_NO_CORRECT_VIA)
    TL_WARN(TF_DIAG) [0]0E5C.1220::01/09/2009-14:36:47.478.000b344d (SIPStack,SIPAdminLog::TraceDiagRecord:1224.idx(142))$$begin_record
    LogType: diagnostic
    Severity: warning
    Text: Routing error occurred; check Result-Code field for more information
    Result-Code: 0xc3e93f04 SIPPROXY_E_REQUEST_NO_CORRECT_VIA
    SIP-Start-Line: INVITE sip:homer@rnddev.computer-talk.com SIP/2.0
    SIP-Call-ID: e0a943e5ab374ce392ceb3da890f2d47
    SIP-CSeq: 1 INVITE
    Peer: 192.168.201.21:3967
    $$end_record
    Friday, January 9, 2009 3:02 PM