[asterisk-bugs] [Asterisk 0018201]: Exchange UM and SIP 302 sets Diversion on INVITE

Asterisk Bug Tracker noreply at bugs.digium.com
Mon Nov 1 15:04:34 CDT 2010


The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18201 
====================================================================== 
Reported By:                rsw686
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18201
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.8.0 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-10-24 08:38 CDT
Last Modified:              2010-11-01 15:04 CDT
====================================================================== 
Summary:                    Exchange UM and SIP 302 sets Diversion on INVITE
Description: 
When a call goes into Exchange UM on port 5060 it send back a SIP 302 Moved
Temporarily with port 5065 or 5067. With Asterisk 1.6.1 and 1.6.2
everything worked. With Asterisk 1.8 a Diversion: reason=unconditional
header is added to the INVITE sent back to Exchange UM added due to the 302
response.

Exchange UM uses the Diversion header to know which mailbox to play the
greeting for. When no Diversion header is present it provides voice mail
access to check messages. Since there is always a Diversion header you
can't access voice mail.

I've temporarily added the following to add_diversion_header so that the
Diversion header isn't added when unconditional. This fixes the problem,
but isn't the correct way to handle this

if(pvt->owner->redirecting.reason == AST_REDIRECTING_REASON_UNCONDITIONAL)
    return;
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-11-01 15:04 lmadsen        Description Updated                          
======================================================================




More information about the asterisk-bugs mailing list