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

Tue Apr 26 08:04:09 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:                     acknowledged
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 08:04 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

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

---------------------------------------------------------------------- 
 (0134114) lmadsen (administrator) - 2011-04-26 08:04
 https://issues.asterisk.org/view.php?id=19154#c134114 
---------------------------------------------------------------------- 
Using ASCII, do I understand this right?

      SIP               SIP               SIP
1689 ----> [research1] ----> [research2] ----> 1690
 \/                                            /\
  \___________________________________________/
                    AUDIO

Is it possible the research2 is not doing the hand off directly? It seems
like the call might be getting setup and research1 and research2 are
getting confused as to how to reinvite the media between the two devices.

Have you tried the directrtpsetup option instead?

;directrtpsetup=yes             ; Enable the new experimental direct RTP
setup. This sets up
                                ; the call directly with media peer-2-peer
without re-invites.
                                ; Will not work for video and cases where
the callee sends
                                ; RTP payloads and fmtp headers in the 200
OK that does not match the
                                ; callers INVITE. This will also fail if
directmedia is enabled when
                                ; the device is actually behind NAT. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-04-26 08:04 lmadsen        Note Added: 0134114                          
======================================================================