[asterisk-bugs] [Asterisk 0010868]: 1.4.11 Stable - Polycom phones hang up when media is re-invited while resuming from an on-hold state

noreply at bugs.digium.com noreply at bugs.digium.com
Mon Oct 8 06:43:00 CDT 2007


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10868 
====================================================================== 
Reported By:                mavince
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   10868
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-02-2007 09:23 CDT
Last Modified:              10-08-2007 06:43 CDT
====================================================================== 
Summary:                    1.4.11 Stable - Polycom phones hang up when media is
re-invited while resuming from an on-hold state
Description: 
PSTN calls made with Polycom phones (several different firmware loads) hang
up when resuming the call from a hold state. 

The call flow connects a Polycom phone to a PSTN phone through a SONUS
gateway with the media passing directly from to/from the Polycom phone. 

Call Scenario: The call can be initiated and answered in either direction,
to or from the PSTN. RTP is successfully provided. If the Polycom phone end
places the call on hold, MOH will be heard. If the Polycom phone then
attempts to resume the call, Asterisk issues two nearly simultaneous
INVITEs with an incremented CSeq, resulting in a 491 - Request Pending (the
appropriate response). Asterisk acknowledges the 491 and then hangs up the
call! I can reproduce the call behavior consistently.

Key points: media is passing directly to Polycom phone, call can be placed
on-hold successfully, other phones Snom, Aastra work correctly with the
same configuration. When media traverses the Asterisk, a Polycom based call
works correctly.

See Bug Tracker Issue 0009921
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0009921 1.4.4 sends Re-INVITE twice, resulting ...
related to          0009431 Modify connection: Response 491 not han...
====================================================================== 

---------------------------------------------------------------------- 
 ramonpeek - 10-08-07 06:43  
---------------------------------------------------------------------- 
Hello everyone..

Me and my colleague (tbelder) entered issue 10696 in the bugtracker.
Which, after some further investigation, seems to be related to this one.

However in our case we have problems (running 1.4.12) in both Attended as
Unattended transfers on Thomson phones
Looking at the problems occuring when doing an attended transfer, I
immediatly see the same issue occuring as stated here. (2x INVITE to put
the active call-leg on-hold) (Thanks to Olle for helping me out with this
one... ;-) ) 

However, when I look at the traces made during an unattended transfer I
can see that putting the call-leg back into the MOH works fine. But that
Asterisk starts re-inviting the transferrer after he has already
transferred the RTP stream back to asterisk... which I feel in incorrect.
After that it clear to see that the phone doesn't expect the message and
ignores it, however asterisk start retransmitting the request after the T1
timer expires and thus a call is initiated with no RTP stream... (ghost
calls.)

I've uploaded the two different traces for you all to see.
Perhaps anyone could find some use in them

I am starting to believe that the problem is really occuring in an earlier
state than where the current patch to rtp.c is written.
Cause in my system too this patch solves the problem only partially on
attended transfer, but the problem still exists on unattended transfers.
Here we can see that there is still an second (unwanted) Re-INVITE.

Anyone, any comments or suggestions... 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-08-07 06:43  ramonpeek      Note Added: 0071624                          
======================================================================




More information about the asterisk-bugs mailing list