locked
Call hold failed at communicator with a phone call to asterisk (via openser) RRS feed

  • Question

  • high.*!

    I've a quite similar problem. I'm currently integrating asterisk via openSER to the OCS 2007 environment. Normal call setup/clearing is fine already but when performing a hold on the communicator, I'm not able to unhold it (cause the hold button is still active) while getting the error message:
    "An error occurred while trying to place the call on hold. Please try again. If the problem persists, contact your system administrator. More details (ID:491)"

    Following scenario: I start a call at the communicator, which is forwarded via OCS mediation server -> openser -> asterisk and i trigger a call hold at the communicator.
    Now though the communicator issues the re-INVITE (hold), it doesn't shows the session is on hold (the hold button in the communicator is still active).

    So somehow i guess it has something to do with the SIP/SDP message "200 OK" which is sent back from asterisk (via openSER). In the re-INVITE (hold) message i see, that the SDP option "a=inactive" is issued, but the reply ("200 OK") looks pretty the normal in the SDP part (like from an initial INVITE). Somehow I think this reply must include something like "a=inactive", right?
    Well my problem is that i do not exactly know, what OCS (mediation server) expects in this reply message. Is there a detailed description of the SIP protocol the OCS mediation server uses?

    Here you can see the re-INVITE and below the reply from asterisk (which causes the OC not to disable the deactivate the hold button):


    Code Snippet

    [  Method INVITE from 172.23.26.121:1678 (2)  ]
    INVITE sip:+43517774001@172.29.223.209;user=phone SIP/2.0
    FROM: <sip:hugo2@msxifx.com>;epid=09A8317F78;tag=1516a7b58d
    TO: <sip:+43517774001@172.29.223.209;user=phone>;tag=as7168dc82
    CSEQ: 494 INVITE
    CALL-ID: 99ad9c16-a965-4e43-a997-21623c4ba2d0
    MAX-FORWARDS: 70
    VIA: SIP/2.0/TCP 172.23.26.121:1678;branch=z9hG4bKde554417
    CONTACT: <sip:MUXSA102.xeu.msxifx.com:5060;transport=Tcp;maddr=172.23.26.121;ms-opaque=d77be698cfea6dfb>
    CONTENT-LENGTH: 268
    SUPPORTED: 100rel
    USER-AGENT: RTCC/3.0.0.0 MediationServer
    CONTENT-TYPE: application/sdp; charset=utf-8

    v=0
    o=- 0 0 IN IP4 172.23.26.121
    s=session
    c=IN IP4 172.23.26.121
    b=CT:1000
    t=0 0
    m=audio 62144 RTP/AVP 0 101
    c=IN IP4 172.23.26.121
    a=rtcp:62145
    a=inactive
    a=label:Audio
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=ptime:20
    [  End of Request (2)  ]




    Code Snippet

    [  Reply 200 (OK) from 172.29.223.210:5060 concerning INVITE  ]
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 172.29.223.209;branch=z9hG4bKe6a.015e5887.0;i=1;received=172.29.223.209
    Via: SIP/2.0/TCP 172.23.26.121:1678;branch=z9hG4bKde554417
    From: <sip:hugo2@msxifx.com>;epid=09A8317F78;tag=1516a7b58d
    To: <sip:+43517774001@172.29.223.209;user=phone>;tag=as7168dc82
    Call-ID: 99ad9c16-a965-4e43-a997-21623c4ba2d0
    CSeq: 494 INVITE
    User-Agent: Asterisk PBX
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
    Contact: <sip:+43517774001@172.29.223.210>
    Content-Type: application/sdp
    Content-Length: 218

    v=0
    o=root 1443 1444 IN IP4 172.29.223.210
    s=session
    c=IN IP4 172.29.223.210
    t=0 0
    m=audio 17666 RTP/AVP 0 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=silenceSupp:off - - - -
    [  End of Reply  ]



    Hope anyone has an idea, what's wrong here...

    thx & cheers
    -hugo
    Wednesday, April 16, 2008 2:49 PM

All replies

  • Hello,

    Since this was not answered and in case somebody stumbles upon this post experiencing the same (since even the latest version of Asterisk 1.6.1-rc1 experinces this) here is the link that will detail this (OCS not conforming to RFC and Asterisk not being work around ) and will help you to remedy the problem. Just merge the changes into chan_sip.c, run "make" again, replace chan_sip.so, and add the 'ignoresdpversion' option to sip.conf. And it works perfectly after that. The link is http://bugs.digium.com/view.php?id=13958

    Hop it helps.

    Friday, February 27, 2009 5:12 PM