[Home]

Summary:ASTERISK-18340: CLONE - directmedia or reinvite not working when calling extension that's located an a different asterisk node
Reporter:Thomas Arimont (tomaso)Labels:
Date Opened:2011-08-24 08:55:02Date Closed:2011-09-26 08:48:25
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.3 1.8.4 1.8.5.0 Frequency of
Occurrence
Related
Issues:
causesASTERISK-19095 REGRESSION after r336294: Music on hold when sip call is put on hold doesnt work anymore after 1.8.8.0-rc1
causesASTERISK-18610 ERRORs since changeset 336294 (Fix bad RTP media bridges)
is a clone ofASTERISK-17725 directmedia or reinvite not working when calling extension that's located an a different asterisk node
Environment:Attachments:( 0) conf-research1.tar.gz
( 1) conf-research2.tar.gz
( 2) directmedia-yes.png
( 3) research-reinvite.png
( 4) sip-trace-callee.txt
( 5) sip-trace-caller.txt
( 6) tests-all-with-same-config.tar.gz
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@default:1] Dial("SIP/1691-0000004a", "SIP/1689:1234::research1@192.168.51.88,20") in new stack
 == Using SIP RTP CoS mark 5
   -- Called 1689:1234::research1@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@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@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@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



****** STEPS TO REPRODUCE ******

1) Setup two asterisk virtual machines on CentOS 5.6 (probably not relevant) and call them "research1" and "research2". These machines should be located on the same machine to reduce the possibility that this very report is valid only due to fast network topology.

2) Use the configurations from the additional info below on the appropriate node (sip.conf and extensions.conf).

3) Setup two telephones with extension 1690 and 1691 on "research1"

4) Setup one telephone with extension 1689 "research2"

(NOTE: I'm using a mixed setup of OpenStage 60 and OpenStage 80 phones.)

5) Open AMI on both nodes.

6) Use "core set debug 7" to get verbose debugging output.

7) Test that this is working: Dial 1690 on telephone with extension 1691 and accept the call. You should make a call without problems in the opposite direction, too.

8) Call 1689 from telephone with extension 1690 or 1691 and accept the call. You should hear nothing!

****** ADDITIONAL INFORMATION ******

extensions.conf on "research1" node:
------------------------------------

[default]
exten => 1689,1,Dial(SIP/1689:1234::research1@192.168.51.88,20)
exten => 1690,1,Dial(SIP/1690,20)
exten => 1691,1,Dial(SIP/1691,20)


sip.conf on "research1" node:
-----------------------------

[1690]
type=friend
secret=1234
dtmfmode=info
qualify=yes
host=dynamic
call-limit=10
directmedia=yes

[1691]
type=friend
secret=1234
dtmfmode=info
qualify=yes
host=dynamic
call-limit=10
directmedia=yes

[research2]
type=peer
username=research2
directmedia=yes
secret=1234
host=dynamic
fromuser=research2


extensions.conf on "research2" node:
------------------------------------

[default]
exten => 1689,1,Dial(SIP/1689,15)
exten => 1690,1,Dial(SIP/1690:1234::research2@192.168.51.253,15)
exten => 1691,1,Dial(SIP/1691:1234::research2@192.168.51.253,15)


sip.conf on "research2" node:
-----------------------------

[1689]
type=friend
secret=1234
dtmfmode=info
qualify=yes
host=dynamic
call-limit=10
directmedia=yes

[research1]
type=peer
username=research1
secret=1234
directmedia=yes
host=dynamic
fromuser=research1
Comments:By: Thomas Arimont (tomaso) 2011-08-24 10:23:08.439-0500

This CLONE handles exact the same issue as ASTERISK-17725. The specific details (config, traces) are still valid especially for Version 1.8.5.0.
In the environment of two coupled asterisk via SIP trunk a call across the two asterisks from a near SIP endpoint to another far SIP endpoint does not lead to a bi-directional direct RTP media stream between the sip endpoints.
In all observed cases one final Re-Invite(SDP) towards one of the participating SIP endpoints is missing which leads to the following resulting RTP media streams:
{noformat}

            asterisk 1          asterisk 2
              /   \
subscr A  --- RTP -------------       ---> subscr B
         <-------------------------- RTP --------

{noformat}

Since the OpenStage IP phone does not support asymmetric RTP streams, both ends does not hear each other at all in this situation. When using other IP phones (like SNOM 360) conversation might be possible, but still without using a complete bi-directional direct RTP media stream.
The problem might have something do to with the trigger for a SIP Re-Invite in remote_bridge_loop()/rtp_engine.c which should be done by invoking update_peer(), but not happens in all cases.
By: Michael Spiceland (mspiceland) 2011-08-25 09:49:51.120-0500

We have been able to replicate this issue in our lab.  We will update this issue once a developer has been able to look into it.  As a related note for said developer: if we set one of the boxes to directmedia=no, the audio path works as expected.
By: Leif Madsen (lmadsen) 2011-09-26 08:48:25.096-0500

This is supposed to be closed per the commit message.