[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-08-2007 18:56 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-08-07 18:56  
---------------------------------------------------------------------- 
Quick Update: The culprit is line 17265 transmit_reinvite_with_sdp(p).
It gets hit at soon as PeerB answers - everytime canreinvite is set to yes
and using t (and other) dial() options.
Cannot work out how/why this is getting a match.

Additional debug messages added and show as follows:

Canreinvite=yes (one way audio):

    -- Executing [3 at airnetmainivr:9] Dial("SIP/202.137.240.83-0821dcc8",
"SIP/66502222|10|t") in new stack
[Sep  9 08:54:02] NOTICE[24644]: chan_sip.c:17157 sip_get_rtp_peer: HIT:
chan->_state != AST_STATE_UP && !global_directrtpsetup
[Sep  9 08:54:02] NOTICE[24644]: chan_sip.c:17182 sip_get_rtp_peer: HIT:
ast_test_flag(&p->flags[0], SIP_CAN_REINVITE
    -- Called 66502222
    -- SIP/66502222-08278c70 is ringing
[Sep  9 08:54:02] NOTICE[24644]: chan_sip.c:17182 sip_get_rtp_peer: HIT:
ast_test_flag(&p->flags[0], SIP_CAN_REINVITE
[Sep  9 08:54:02] NOTICE[24644]: chan_sip.c:17157 sip_get_rtp_peer: HIT:
chan->_state != AST_STATE_UP && !global_directrtpsetup
PICKED UP HANDSET HERE
   -- SIP/66502222-08278c70 answered SIP/202.137.240.83-0821dcc8
[Sep  9 08:54:10] NOTICE[24644]: chan_sip.c:17182 sip_get_rtp_peer: HIT:
ast_test_flag(&p->flags[0], SIP_CAN_REINVITE
[Sep  9 08:54:10] NOTICE[24644]: chan_sip.c:17182 sip_get_rtp_peer: HIT:
ast_test_flag(&p->flags[0], SIP_CAN_REINVITE
[Sep  9 08:54:10] NOTICE[24644]: chan_sip.c:17282 sip_set_rtp_peer: HIT:
transmit_reinvite_with_sdp thing
[Sep  9 08:54:10] NOTICE[24644]: app_dial.c:1601 dial_exec_full: HIT:
app_dial.c OPT_CALLEE_TRANSFER
HANGUP HANDSET HERE
[Sep  9 08:54:17] WARNING[24644]: app_dial.c:1654 dial_exec_full: HIT: App
Dial.c ast_bridge_call
  == Spawn extension (airnetmainivr, 3, 9) exited non-zero on
'SIP/202.137.240.83-0821dcc8'


Canreinvite=no (audio good):

    -- Executing [3 at airnetmainivr:9] Dial("SIP/202.137.240.83-b7307080",
"SIP/66502222|10|t") in new stack
[Sep  9 10:27:00] NOTICE[10774]: chan_sip.c:17160 sip_get_rtp_peer: HIT:
chan->_state != AST_STATE_UP && !global_directrtpsetup
[Sep  9 10:27:00] NOTICE[10774]: chan_sip.c:17185 sip_get_rtp_peer: HIT:
ast_test_flag(&p->flags[0], SIP_CAN_REINVITE
    -- Called 66502222
    -- SIP/66502222-08268cb0 is ringing
[Sep  9 10:27:00] NOTICE[10774]: chan_sip.c:17185 sip_get_rtp_peer: HIT:
ast_test_flag(&p->flags[0], SIP_CAN_REINVITE
[Sep  9 10:27:00] NOTICE[10774]: chan_sip.c:17160 sip_get_rtp_peer: HIT:
chan->_state != AST_STATE_UP && !global_directrtpsetup
PICKED UP HANDSET HERE
   -- SIP/66502222-08268cb0 answered SIP/202.137.240.83-b7307080
[Sep  9 10:27:05] NOTICE[10774]: chan_sip.c:17185 sip_get_rtp_peer: HIT:
ast_test_flag(&p->flags[0], SIP_CAN_REINVITE
[Sep  9 10:27:05] NOTICE[10774]: app_dial.c:1601 dial_exec_full: HIT:
app_dial.c OPT_CALLEE_TRANSFER
HANGUP HANDSET HERE
[Sep  9 10:27:12] NOTICE[10774]: app_dial.c:1654 dial_exec_full: HIT: App
Dial.c ast_bridge_call
  == Spawn extension (airnetmainivr, 3, 9) exited non-zero on
'SIP/202.137.240.83-b7307080' 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-08-07 18:56  samdell3       Note Added: 0070196                          
======================================================================