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

[Asterisk Bug Tracker]

The following issue has been CLOSED 
====================================================================== 
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:                     closed
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:              
Resolution:                 open
Fixed in Version:           
====================================================================== 
Date Submitted:             2011-04-20 07:56 CDT
Last Modified:              2011-04-20 14:59 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


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

---------------------------------------------------------------------- 
 (0133992) pabelanger (administrator) - 2011-04-20 14:59
 https://issues.asterisk.org/view.php?id=19154#c133992 
---------------------------------------------------------------------- 
This looks to be a configuration issue, not a bug.  Specifically, you are
not using your peer definitions for your research peers.

---
Thanks for your comments. This does not appear to be a bug report and we
are closing it. We appreciate the difficulties you are facing, but it would
make more sense to raise your question in the support tracker,
http://www.asterisk.org/support 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-04-20 14:59 pabelanger     Note Added: 0133992                          
2011-04-20 14:59 pabelanger     Status                   new => closed       
======================================================================