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

Asterisk Bug Tracker noreply at bugs.digium.com
Sun Oct 24 08:38:25 CDT 2010


The following issue has been SUBMITTED. 
====================================================================== 
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:                     new
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-10-24 08:38 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-10-24 08:38 rsw686         New Issue                                    
2010-10-24 08:38 rsw686         Asterisk Version          => 1.8.0           
2010-10-24 08:38 rsw686         Regression                => No              
2010-10-24 08:38 rsw686         SVN Branch (only for SVN checkouts, not tarball
releases) => N/A             
======================================================================




More information about the asterisk-bugs mailing list