Re: [Opalvoip-user] Hold behavior with Avaya SIP Server

[Robert J. <ro...@vo...>]

As these sort of problem tend to crop up on certain software, and certain
versions of software, there are mechanisms for working around them that do
not involve breaking the compliant behaviour.

That scenarios is covered by adding the remote systems name (obtained via
User-Agent header) to the OPAL_OPT_SYMMETRIC_HOLD_PRODUCT option string.
See documentation in sdpep.h

Is this good enough to solve your problem?


Robert Jongbloed
*OPAL/OpenH323/PTLib Architect and Co-founder*.

On 1 July 2015 at 17:57, Dicke James (ST-CO/ENG2.2) <
Jam...@us...> wrote:

>  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
>
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Opalvoip-user mailing list
> Opa...@li...
> https://lists.sourceforge.net/lists/listinfo/opalvoip-user
>
>