[asterisk-bugs] [Asterisk 0013531]: Hold logic broken?

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13531 
====================================================================== 
Reported By:                sgofferj
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13531
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.0-rc6 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-09-22 04:53 CDT
Last Modified:              2008-10-09 16:56 CDT
====================================================================== 
Summary:                    Hold logic broken?
Description: 
I have the following symptoms:

Call X-lite / Nokia E51
X-lite press hold: Nokia DOES hear MOH
Nokia press hold: X-lite does NOT hear MOH

Call X-lite / SCCP phone
MOH works as supposed

Call SCCP phone / Nokia E51
SCCP press hold: Nokia DOES hear MOH
Nokia press hold: X-lite does NOT hear MOH

In addition, the BLF on the SCCP phones does NOT show the hinted SIP
extension on hold.

With 1.4 latest, everything worked as supposed.
As this problem appears also between SIP clients, it is NOT a
chan_sccp-related issue.

====================================================================== 

---------------------------------------------------------------------- 
 (0093426) putnopvut (administrator) - 2008-10-09 16:56
 http://bugs.digium.com/view.php?id=13531#c93426 
---------------------------------------------------------------------- 
I took a look at the traces, and I must say that the nokia_calls_xlite.txt
has some strange things in it, and they don't appear to be Asterisk's fault
from what I can tell.

As a point of reference, let me first point to the re-INVITE used by the
Nokia in the xlite_calls_nokia.txt file. It is about half-way down the
page, and has a Cseq of "1 INVITE" . This is a fairly normal re-INVITE to
place the far end on hold, in that there is an a=sendonly line in the SDP.

Now, for some reason, if you look at nokia_calls_xlite.txt, you'll see
that at timestamp 13:36:43, there are *3* re-INVITE transactions that take
place. The first re-INVITE Asterisk receives (Cseq 786 INVITE) is once
again a normal re-INVITE to place the far end on hold. Asterisk responds
with a 200 OK and reads the ACK sent by the Nokia. Then, for some reason,
the Nokia decides to initiate two more INVITE transactions. In each case,
the INVITE is properly responded to with a 200 OK. In the second re-INVITE
that the Nokia sends (Cseq 787 INVITE), it has a bizarre SDP with an
a=sendonly and an a=sendrecv line. Then, the third re-INVITE that the Nokia
sends (Cseq 788 INVITE) has an SDP with just an a=sendrecv line. It's at
this point that the Nokia stops initiating any new re-INVITE transactions.

While I think it is bizarre that this is happening, I have noticed
something a bit odd that Asterisk is doing which may be contributing. If
you look at xlite_calls_nokia.txt, in response to the re-INVITE that the
Nokia sends to Asterisk to indicate hold, Asterisk responds with an SDP
with an a=recvonly line. However, if you look at nokia_calls_xlite.txt, in
response to the re-INVITE that the Nokia sends to Asterisk to indicate
hold, Asterisk responds with an SDP with an a=sendrecv line. This may
actually be what is causing the Nokia to get "confused" and send new
re-INVITEs to Asterisk. I'll have a closer look at this. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-09 16:56 putnopvut      Note Added: 0093426                          
======================================================================