[asterisk-bugs] [Asterisk 0010647]: SIP Reinvite behaviour does not work as expected with certain dial() options

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10647 
====================================================================== 
Reported By:                samdell3
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10647
Category:                   Core/RTP
Reproducibility:            always
Severity:                   minor
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:             09-05-2007 00:50 CDT
Last Modified:              09-05-2007 17:47 CDT
====================================================================== 
Summary:                    SIP Reinvite behaviour does not work as expected
with certain dial() options
Description: 
With canreinvite=no on any SIP peer, the call is never reinvited (this is
correct behaviour)

With canreinvite=yes, and using with a Dial() option from below,
re-invites are not issued correctly. (actually, reinvites should not be
issued at all...)

Asterisk is not supposed to perform a re-invite when using any of the
following Dial() options: t, T, h, H, w, W or L (with multiple arguments)
This is not the case. 
Asterisk still issues a Re-invite to one of the call legs causing an
asytmetrical RTP traffic flow (causing one-way audio if the SIP peer
filters RTP packets coming from somehwere that was not in it's own SDP)

EG 
SIPPeerA------ASTERISK-----SIPPeerB

SIPPeerA calls SIPPeerB

If either or both SIPPeerA or SIPPeerB have canreinvite=no, the RTP flow
is always via Asterisk - this is correct.

If Both SIPPeers are canreinvite=yes, AND the dial command contains any of
the above dial() options, then the RTP flow forms a triangle due to a
single re-invite STILL being issued by Asterisk. EG A's RTP goes to
Asterisk, Asterisk's RTP goes to B, but B's RTP goes to A. This is because
Asterisk issues a re-invite and tells B to talk to A when it shouldn't. 
If Asterisk does issue a re-invite for one leg, it should issue a
re-invite for both legs! But in this case it should not issues any
re-invites at all.
====================================================================== 

---------------------------------------------------------------------- 
 samdell3 - 09-05-07 17:47  
---------------------------------------------------------------------- 
Verbose debug attached
SIP capture's attached (2 vantage points, Asterisk and SIP PeerB)
Edited sip.conf attached

PeerA = SIP Gateway
PeerB = Polycom Handset

Test call came in via PeerA, to IVR at Asterisk. Option 3 pressed, causing
PeerB to be dialled with t option and canreinvite=yes. picked up PeerB's
handset, with one way audio problem. PeerB cannot hear anything, but PeerA
can hear PeerB
You can see the 'triangle' RTP Flow in 'sniffedAtPeerB.cap'. 
Polycom handsets, by default, filter RTP traffic sent to it that was not
negotiated in the SDP, becasue it was never sent the re-invite

NOTE: PeerB has a 10.x.x.x address. It is *NOT* behind NAT, rather, a
private routed network at layer 3. PeerA and Asterisk are in the same
public subnet. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-05-07 17:47  samdell3       Note Added: 0069987                          
======================================================================