[Opalvoip-user] Hold behavior with Avaya SIP Server

[Dicke J. (ST-CO/ENG2.2) <Jam...@us...>]

Hello all,

I have encountered an issue with the OPAL Library pertaining to some unexpected SIP on-hold message responses generated by Avaya Call Manager 6.2.

The steps to reproduce the issue are as follows:
1.      Establish a call
2.      Place the call on hold.
3.      Take the call off hold.  Result: the call does not return from hold state.

After performing a Wireshark trace and reading up on various RFCs defining SIP Hold behavior, I summarize the behavior as the following:

The call is established
1.      OPAL receives an invite with media attribute "sendrecv"

The user places the call on hold
1.      OPAL sends an invite with media attribute "sendonly"
2.      Avaya SIP server responds with OK specifying "inactive".  (The typical/expected response is "recvonly")

The user takes the call off hold:
1.      OPAL sends an invite with media attribute "recvonly".  (The typical/expected command is "sendrecv")
2.      Avaya SIP server responds with OK specifying "sendonly".  The call is never properly restored to "sendrecv" state.

RFC 6337 Section 5.3 defines SIP Hold behavior, and from my understanding, it appears that the Avaya's response of "inactive" is technically valid in the case that no on-hold music is desired, but the behavior may be "non-normative".  It specifies that to "resume a two-way exchange of media, each side must reset its local hold status.  If UA1 is first to go off hold, it will then send an offer with "a=sendrecv" attribute".  However, OPAL is currently sending "recvonly" in this situation.

While the problem was initially encountered using an older version of the OPAL library, I was able to reproduce the problem using OpenPhone 3.14.3.  I have included a PTrace log and Wireshark (v1.1.12.2) trace that captures the issue.

Jumping into the code, I have implemented a simple fix, but I am wary of undesired side effects.  In SIPConnection::OnSendOfferSDPSession, two Boolean variables sending and recving are determined, and used to set the local media direction.  Upon taking the call off hold, I set a breakpoint prior to setting the local media direction, and observed the variables in the following state:
*       sendStream->IsOpen() is true
*       sendStream ->IsPaused() is true
*       As a result of (!sendStream ->IsPaused()), sending is set to false
*       m_holdFromRemote is true
*       m_holdToRemote is eRetrieveInProgress

As a result of observing these variable states, I added the following code:

if (sendStream != NULL && sendStream->IsOpen() && sendStream->IsPaused() && m_holdFromRemote)
{
  sending = true
}

It appears to fix the issue.  Do you see any unforeseen consequences, or is there a better way to address the issue?

Any assistance would be greatly appreciated!


Thank you and best regards,

James Dicke

Bosch Security Systems, Inc.
Communications Systems Division
Design Engineer