none
UCMA 3.0 and MediaProvider - SetAnswer gives strange status

    Question

  • Hi all,

    Im about to port my modified B2B client to lync. Basiclly I have modified the SDPs so I can controll a MRCP server. It works fine in UCMA 2.0, however when I use Lync (UCMA 3.0) I get a strange status from the:

    protected

     

     

    override void SetAnswer(OfferAnswerContext offerAnswerContext, SdpOffer originalOffer, SdpAnswer answer)

     

     

    method - the answer contains UnsupportedMediaCanRetry, when I suppose to get Final as status.

    What have happend in this area? Do I have to extend someting? Do I have to modify my ApplicationEndpoint to support more MediaTypes? I have extend the call to support a new media type, as in ACD sample for ApplicationSharingCall...

    Any ideas?

    Thanks
    Andreas

    Tuesday, November 30, 2010 10:11 AM

All replies

  • I can clearify things... The problem is the SDP data Lync recieves from the MRCP server. The SDP looks like this and i suppose the bold text is the problem:

    v=0
    o=- 0 0 IN IP4 192.168.100.116
    s=-
    c=IN IP4 192.168.100.116
    t=0 0
    m=audio 4000 RTP/AVP 0
    a=rtpmap:0 PCMU/8000
    a=sendonly
    a=ptime:20
    a=mid:1
    m=application 1544 TCP/MRCPv2 1
    a=setup:passive
    a=connection:new
    a=channel:bc93e7804df10b46@speechsynth
    a=cmid:1

    This work before on OCS :/ and now I will get UnsupportedMediaCanRetry in SetAnswer...

    This is what the MRCP server has logged:

    2010-12-01 10:26:37:376451 [INFO]   Receive SIP Event [nua_i_invite] Status 100 Trying
    2010-12-01 10:26:37:376451 [INFO]   Receive SIP Event [nua_i_state] Status 100 Trying
    2010-12-01 10:26:37:376451 [NOTICE] SIP Call State [received]
    2010-12-01 10:26:37:377451 [INFO]   Found Profile [MRCPv2-Default]
    2010-12-01 10:26:37:377451 [INFO]   Remote SDP
    //removed SDP
    2010-12-01 10:26:37:380451 [NOTICE] Add Session <bc93e7804df10b46>
    2010-12-01 10:26:37:381451 [INFO]   Receive Offer <bc93e7804df10b46> [c:1 a:1 v:0]
    2010-12-01 10:26:37:381451 [INFO]   Create Channel <1>
    2010-12-01 10:26:37:381451 [INFO]   [CHANNEL      1] create channel {0050D270}
    2010-12-01 10:26:37:381451 [INFO]   Channel <1> created {0050D270}
    2010-12-01 10:26:37:381451 [INFO]   Add Control Channel <bc93e7804df10b46@speechsynth> to Pending Connection [1]
    2010-12-01 10:26:37:383451 [INFO]   Open RTP Transmitter 192.168.100.116:4000 -> 192.168.100.116:7330
    2010-12-01 10:26:37:383451 [INFO]   Source->[LPCM/8000/1]->Bridge->[LPCM/8000/1]->Encoder->[PCMU/8000/1]->Sink
    2010-12-01 10:26:37:383451 [INFO]   Open Channel <1>
    2010-12-01 10:26:37:383451 [INFO]   [CHANNEL      1] open channel, session <bc93e7804df10b46>
    2010-12-01 10:26:37:383451 [INFO]   Channel <1> opened, session <bc93e7804df10b46>
    2010-12-01 10:26:37:383451 [INFO]   Send Answer <bc93e7804df10b46> [c:1 a:1 v:0] Status OK
    2010-12-01 10:26:37:383451 [INFO]   Local SDP
    //removed SDP
    2010-12-01 10:26:37:391451 [INFO]   Receive SIP Event [nua_i_state] Status 200 OK
    2010-12-01 10:26:37:391451 [NOTICE] SIP Call State [completed]

    Everything seams to work as it should on the MCRP server side.

    //Andreas

    • Edited by Skakiz Wednesday, December 01, 2010 9:41 AM Added log from MRCP server
    Wednesday, December 01, 2010 9:34 AM
  • I have tries stripping down my B2B implementations to be an ordinary B2B with no additionall SDP. Its exacly as the sample program in ACD on UCMA 2.0. But I still get the same Status back. Does that B2BCall work in Lync with UCMA 3.0?

    //Andreas

     

    Wednesday, December 01, 2010 10:22 AM
  • I have traced the lync server and can see that I get an exception:

    TL_VERBOSE(TF_COMPONENT) [1]9FB8.7DF0::12/01/2010-13:33:17.750.00001258 (Collaboration,SipAsyncResult2<TEx>.Complete:asyncresult2.cs(589))(03A32DEC)<SignalingSession_16159884||SipInviteAsyncResult_61025772> Completing operation: Microsoft.Rtc.Signaling.SipInviteAsyncResult, Exception: Exception: Microsoft.Rtc.Signaling.FailureResponseException
    > ResponseData.ResponseCode: 415
    > ResponseData.ResponseText: Unsupported Media Type
    > ResponseData.SignalingHeaders: System.Collections.Generic.List`1[Microsoft.Rtc.Signaling.SignalingHeader]
    > ResponseData.FromHeader.Uri: sip:mcrpclient@xxx.com
    > ResponseData.FromHeader.Epid: 7EF3808EC3
    > ResponseData.FromHeader.HeaderValue: "MRCP Client"<sip:mcrpclient@xxx.com>;epid=7EF3808EC3;tag=0b5c6102
    > ResponseData.FromHeader.DisplayName: MRCP Client
    > ResponseData.FromHeader.Tag: 0b5c6102
    > ResponseData.ToHeader.Uri: sip:test@test.com
    > ResponseData.ToHeader.Epid:
    > ResponseData.ToHeader.HeaderValue: <sip:test@test.com>;tag=NNQQeF04jy1yg
    > ResponseData.ToHeader.DisplayName:
    > ResponseData.ToHeader.Tag: NNQQeF04jy1yg
    > ResponseData.CSeq: 8
    > ResponseData.RequestUri:
    > ResponseData.UserAgent: UniMRCP SofiaSIP
    > ResponseData.CallId: a02969ad-0bfb-413c-8e0d-75e065919cd3
    > DiagnosticInformation: ErrorCode=1037,Source=gimlet.xxx.com,Reason=Previous hop client did not report diagnostic information
    Microsoft.Rtc.Signaling.DiagnosticHeader

    > WarningInformation: System.Collections.ObjectModel.Collection`1[Microsoft.Rtc.Signaling.WarningHeader]
    > DetectionStackTrace:    at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
       at System.Environment.get_StackTrace()
       at Microsoft.Rtc.Signaling.Helper.get_StackTrace()
       at Microsoft.Rtc.Signaling.RealTimeException..ctor(String message, Exception innerException)
       at Microsoft.Rtc.Signaling.FailureResponseException..ctor(String message, Exception innerException, SipResponseData responseData)
       at Microsoft.Rtc.Signaling.RealTimeException.GetWrappedRealTimeException(String message, SipResponseData responseData, Exception exceptionToWrap)
       at Microsoft.Rtc.Signaling.Helper.CreateExceptionByType(String message, SipResponseData responseData, Exception innerException, Type exceptionType)
       at Microsoft.Rtc.Signaling.SipTransactionAsyncResult`1.ProcessFailureResponse(SipResponse response)
       at Microsoft.Rtc.Signaling.SipInviteAsyncResult.ProcessFailureResponse(Object state)
       at Microsoft.Rtc.Signaling.QueueWorkItemState.ExecuteWrappedMethod(WaitCallback method, Object state)
       at Microsoft.Rtc.Signaling.QueueWorkItemState.WrappedQueueUserWorkItem(Object state)
       at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
       at System.Threading.ExecutionContext.runTryCode(Object userData)
       at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
       at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
    > Message: A 415 (Unsupported Media Type) response was received from the network and the operation failed. See the exception details for more information.
    > Source: Microsoft.Rtc.Collaboration

    If you guys want more traces, please shout out!

    //Andreas

    Wednesday, December 01, 2010 2:23 PM
  • I have now tried the orginal B2BUA (ACD sample) with not strange surroundings and that works great!!!

    Before i send the outgoing call to a static route... Is that not possible any longer? Or maybe its our new enviroment that is the problem :(

    If you guys get any ideas at all, please tell me.

    Thanks!
    //Andreas

    Thursday, December 02, 2010 8:20 AM
  • I have tested the static route and that is not the problem...

    The only thing that remains is the media type that is sent back to the B2BUA is not supported. The strange thing is that I can send such a media but not recieve it. This is proven by removing the SupportingMediaType, in this case "application", from the Call class. The call wont even get to the destination, but when I have the SupportingMediaType on the sip-call, it gets to destination however the answere is not provided for me... I get the UnsupportedMediaCanRetry. Bug?

    Do somebody on Microsoft have an answere on this? And who can I get in contact with about the problem?

    Thanks!
    Andreas

    Friday, December 03, 2010 10:28 AM
  • The problem is solved, but a new arrived. If I send only one sdp in INVITE message, then i wont get any UnsupportedMediaCanRetry. This is a problem in the SofiaSIP Agent that UniMRCP uses, it only supports one sdp, not multipart/mixed content...

    The new problem is that I wont get any callback on SetAnswere at all.

    I have snooped the communication and can see that the MRCP server sends back a SIP/2.0 200 OK and after that I get:
    TL_WARN(TF_DIAG) [1]0980.0D20::12/07/2010-10:29:03.351.000150a5 (SIPStack,SIPAdminLog::TraceDiagRecord:SIPAdminLog.cpp(145))$$begin_record
    LogType: diagnostic
    Severity: warning
    Text: Message was discarded by the application
    Result-Code: 0xc3e93ec6 SIP_E_AUTH_CANNOT_CHALLENGE
    SIP-Start-Line: SIP/2.0 200 OK
    SIP-Call-ID: 1ff9dda7-f180-44e0-a2a8-55ae2fb61d9b
    SIP-CSeq: 4 INVITE
    Data: application=
    http://www.microsoft.com/LCS/UserServices
    $$end_record

    Has this someting to do with my static route?

    When I run Get-CsStaticRoutingConfiguration I will get:

    Identity : Global
    Route    : {MatchUri=test.com;MatchOnlyPhoneUri=False;Enabled=True;ReplaceHostInRequestUri=False}

    to make the route I have used:

    $x = New-CsStaticRoute -TCPRoute -Destination "192.168.100.116" -Port 8060 -MatchUri "test.com"
    Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$x}

    I will try to draw the system:

    *----------*          *-------------------------*  sip:test@test.com     *-------------*             *-------*
    |   caller   | -----> |      My MRCP client    | -----------------------> |    MRCP     | -------> |  TTS  |
    |              |          |    a B2BUA modified  |                                 |    Server    |             |         |
    *----x-----*          *-------------------------*                                *----x--------*             *-------*
           |__________________________________RTP_______________|

    sip:test@test.com is the static route to 192.168.100.116:8060. The MRCP server will answere and I can see is sends back data in the snoop, as discribed before.

    Any Ideas?

    Thanks!
    Andreas

    Tuesday, December 07, 2010 2:39 PM