[asterisk-bugs] [Asterisk 0019154]: directmedia or reinvite not working when calling extension that's located an a different asterisk node

Tue Apr 26 10:33:47 CDT 2011

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=19154 
====================================================================== 
Reported By:                kwk
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   19154
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.8.3.2 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-04-20 07:56 CDT
Last Modified:              2011-04-26 10:33 CDT
====================================================================== 
Summary:                    directmedia or reinvite not working when calling
extension that's located an a different asterisk node
Description: 
Here's what I want to do:

Create a call that uses a directmedia stream from an extension on one node
to an extension on the other node. In other words, dial 1689 on the
telephone with the extension 1690 or vice versa.

Here's what works:

When calling an extension on the same node as the caller (say 1690 calls
1691) directmedia streaming works.

Heres' what doesn't work:

When the caller (1691) and the caller (1689) lie on different nodes there
is an issue with a SIP 491 Pending event. At least that's what I'm guessing
from this AMI output on both nodes:

    -- Executing [1689 at default:1] Dial("SIP/1691-0000004a",
"SIP/1689:1234::research1 at 192.168.51.88,20") in new stack
  == Using SIP RTP CoS mark 5
    -- Called 1689:1234::research1 at 192.168.51.88
    -- SIP/192.168.51.88-0000004b is ringing
    -- SIP/192.168.51.88-0000004b answered SIP/1691-0000004a
    -- Remotely bridging SIP/1691-0000004a and SIP/192.168.51.88-0000004b
[Apr 20 08:43:55] WARNING[10332]: chan_sip.c:19184 handle_response_invite:
just did sched_add waitid(12704) for sip_reinvite_retry for dialog
085b1fd45be9be4673c17047356a4f3c at 192.168.51.253:5060 in
handle_response_invite
Sent RTP P2P packet to 192.168.51.238:5010 (type 00, len 000160)
Sent RTP P2P packet to 192.168.51.238:5010 (type 00, len 000160)
Sent RTP P2P packet to 192.168.51.238:5010 (type 00, len 000160)
Sent RTP P2P packet to 192.168.51.238:5010 (type 00, len 000160)
Sent RTP P2P packet to 192.168.51.88:18678 (type 08, len 000160)
Sent RTP P2P packet to 192.168.51.238:5010 (type 00, len 000160)
Sent RTP P2P packet to 192.168.51.238:5010 (type 00, len 000160)
[...]
Sent RTP P2P packet to 192.168.51.238:5010 (type 00, len 000160)
  == Spawn extension (default, 1689, 1) exited non-zero on
'SIP/1691-0000004a'
research1*CLI>

Here's the output of the called party (1689) on research2 node:

   -- Executing [1689 at default:1] Dial("SIP/192.168.51.253-0000003c",
"SIP/1689,15") in new stack
  == Using SIP RTP CoS mark 5
    -- Called 1689
    -- SIP/1689-0000003d is ringing
    -- SIP/1689-0000003d answered SIP/192.168.51.253-0000003c
    -- Remotely bridging SIP/192.168.51.253-0000003c and
SIP/1689-0000003d
[Apr 20 08:43:55] WARNING[2882]: chan_sip.c:19184 handle_response_invite:
just did sched_add waitid(8899) for sip_reinvite_retry for dialog
085b1fd45be9be4673c17047356a4f3c at 192.168.51.253:5060 in
handle_response_invite
  == Spawn extension (default, 1689, 1) exited non-zero on
'SIP/192.168.51.253-0000003c'

To sum up what I've experienced:

When the connection from 1691 to 1689 is established (both parties have
picked up the hearer) both ends don't hear anything whereas everything
works (including directmedia set to "yes) when 1690 calls 1691 or vice
versa.

I'm not sure if this very report relates to this one:
https://issues.asterisk.org/view.php?id=12013

Kind regards,
-Konrad

====================================================================== 

---------------------------------------------------------------------- 
 (0134130) kwk (reporter) - 2011-04-26 10:33
 https://issues.asterisk.org/view.php?id=19154#c134130 
---------------------------------------------------------------------- 
The file "tests-all-with-same-config.tar.gz" contains the most recent
config files I'm using for tests. Also they contain images of a graphical
SIP trace. All the images were made with same config files. Please note how
different the RTP flow is and that there isn't any direct connection
between the peers (192.168.51.235 and 192.168.51.236). If the graphical
output was too big, I've split the output in "t?a.png" and "t?b.png".

The images also show the SIP communication between the asterisk nodes now.
This was only possible by moving the research2 box to a different host
(192.168.52.88 has been moved to 192.168.51.62).

I hope the graphical output helps you understand or evaluate the problem.

I've been using "directmedia=yes" explicitly and the default of
"directrtpsetup". 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-04-26 10:33 kwk            Note Added: 0134130                          
======================================================================