locked
Transfer - re-INVITE Hold Invalid Media Description RRS feed

  • Question

  • Hi folks,

     

    I'm getting an error in the event log when I attempt to put a call on hold and the OK comes back after MSS sends the re-INVITE.

     

    Event Type: Error
    Event Source: Office Communications Server 2007 Speech Server
    Event Category: Speech Application
    Event ID: 29025
    Date:  4/30/2007
    Time:  8:40:30 AM
    User:  N/A
    Computer: ERIC01
    Description:
    Application Error 100: An unexpected exception occurred: The SIP peer has responded to a 'hold' request with an invalid media description.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    I'm getting this error when using both xSipPhone and Grandstream devices.

     

    Here's the SDP from xSipPhone:

     

    v=0
    o=8888888 8000 8001 IN IP4 10.0.0.40
    s=SIP Call
    c=IN IP4 10.0.0.40
    t=0 0
    m=audio 5004 RTP/AVP 0 101
    a=sendrecv
    a=rtpmap:0 PCMU/8000
    a=ptime:20
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-11

    And here's the SDP from a Grandstream ht488:

     

    v=0
    o=sipX 5 5 IN IP4 192.168.2.2
    s=phone-call
    c=IN IP4 192.168.2.2
    t=0 0
    m=audio 8766 RTP/AVP 0 101
    a=rtpmap:0 pcmu/8000/1
    a=rtpmap:101 telephone-event/8000/1

     

    Is MSS expecting a=recvonly?  That's a media attribute, not a media description, so it seems like the problem is probably with the m= line.

     

    The call does not fail when this occurs, but after sending 202 Accepted and a NOTIFY back to MSS to acknowledge the REFER, MSS does not OK the NOTIFY.  I'm wondering what's going on under the hood, because MSS did send the REFER, so it wasn't too upset about the invalid media description, but then it ignores the NOTIFY.

     

    Thanks,

     

    EZB

    Monday, April 30, 2007 12:57 PM

Answers

  • Hi Alan,

     

    We resolved the issue.  Sorry, I usually make it a point to respond to my own posts when I figure something out myself.

     

    The NOTIFY problem had something to do with the content-length of the sipfrag being incorrect.

     

    I'm not making any API calls from a workflow, I'm actually implementing a B2BUA to allow MSS to integrate with SIP terminators that don't speak TCP and don't understand REFER.  It's been quite an adventure.  Between MSS, several hardware SIP devices, softphones, and several different endpoints, nobody implements the SIP/SDP/RTP stack consistently.  Supervised transfer has been one of the more challenging issues, but we've got that working well now.

     

    I've had some more odd behaviors from MSS to work around, but as far as things I would actually consider bugs, I've just got one on my list:

     

    If I send a BYE to MSS with a missing max-forwards line, MSS neither OKs the BYE nor sends an error response.  Instead, it basically ignores the BYE *and* closes the TCP connection I have established, so I can't send it any more messages.  Later when the workflow completes, I get a BYE from MSS from a different TCP port, and nothing in the logs indicates a problem.  The spec requires a max-forwards, so I would expect an error response of some kind, but not a silent disconnect.  The workaround was simple from our end, of course (we just append max-forwards to a forwarded request if it's missing), but it seems like something that should be addressed in MSS.

     

    Thanks,

     

    EZB

    Friday, May 11, 2007 3:17 PM

All replies

  • Hi,

     

    Just a quick update: I tried modifying the SDP to add a=recvonly (or replacing a=sendrecv with a=recvonly) and MSS still generated the error in the logs.

     

    And one more question: if this does work as intended and MSS doesn't generate the error, should I expect it to issue another re-INVITE to take the call off hold?  Or is MSS assuming that the endpoint will handle that?

     

    Thanks,

     

    EZB

    Monday, April 30, 2007 2:19 PM
  • Hi Eric,

    Sorry for the delay.

    MSS *is* expecting a=recvonly, as you suspected.  If the endpoint replies with a=sendrecv, it hasn't understood the hold request.  There are two ways of specifying a hold - the old way, via "m=0.0.0.0", and the new way, with "a=sendonly".  MSS understands both, but will only ever issue the latter.  If the SIP phones you're using don't understand the new standard, they might reply with what you're seeing.

     

    For the rest of this response, I'll assume you get that sorted out one way or another, such that whoever MSS is talking to replies correctly with a=recvonly.

     

    The error message you're seeing just means that we didn't like something about the SDP that came back on the 200 OK.  I've run the SDP from your post through our SDP parser, and it parses fine, so it must have tripped one of two conditions:

    - The response didn't have "a=recvonly".  The original SDP would have hit this, but your modified SDP shouldn't.

    - Something else changed: the remote media endpoints have changed, or none of the codecs advertised were in the list originally agreed upon.

     

    I don't see anything in the SDP you provided that looks sketchy, but can you provide a copy of the SDP from the original negotiation?

     

    I'm not sure what's going on with your broader scenario, with the NOTIFY not getting ACK'd.  What API calls did you make in that process, exactly?  Can you provide me with logs of that happening?

    Thursday, May 10, 2007 9:42 PM
  • Hi Alan,

     

    We resolved the issue.  Sorry, I usually make it a point to respond to my own posts when I figure something out myself.

     

    The NOTIFY problem had something to do with the content-length of the sipfrag being incorrect.

     

    I'm not making any API calls from a workflow, I'm actually implementing a B2BUA to allow MSS to integrate with SIP terminators that don't speak TCP and don't understand REFER.  It's been quite an adventure.  Between MSS, several hardware SIP devices, softphones, and several different endpoints, nobody implements the SIP/SDP/RTP stack consistently.  Supervised transfer has been one of the more challenging issues, but we've got that working well now.

     

    I've had some more odd behaviors from MSS to work around, but as far as things I would actually consider bugs, I've just got one on my list:

     

    If I send a BYE to MSS with a missing max-forwards line, MSS neither OKs the BYE nor sends an error response.  Instead, it basically ignores the BYE *and* closes the TCP connection I have established, so I can't send it any more messages.  Later when the workflow completes, I get a BYE from MSS from a different TCP port, and nothing in the logs indicates a problem.  The spec requires a max-forwards, so I would expect an error response of some kind, but not a silent disconnect.  The workaround was simple from our end, of course (we just append max-forwards to a forwarded request if it's missing), but it seems like something that should be addressed in MSS.

     

    Thanks,

     

    EZB

    Friday, May 11, 2007 3:17 PM