[Home]

Summary:ASTERISK-17725: directmedia or reinvite not working when calling extension that's located an a different asterisk node
Reporter:kwk (kwk)Labels:
Date Opened:2011-04-20 07:56:26Date Closed:2011-09-26 08:48:00
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 the original version of this clone:ASTERISK-18340 CLONE - 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: kwk (kwk) 2011-04-20 08:00:59

The steps to reproduce include this line:

"5) Open AMI on both nodes."

This is what I've meant:

"5) Open CLI on both nodes."

By: Paul Belanger (pabelanger) 2011-04-20 14:59:00

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

By: kwk (kwk) 2011-04-26 02:25:40

I've joined #asterisk on IRC and discussed my problems. I've updated my configuration so that it shouldn't be buggy anymore. The configuration I use on the two asterisk nodes "research1" and "research2" as well as the SIP trace when 1690 (on research1) calls 1689 (on research2) will be attached.

I'm pretty sure that this is not a configuration issue.

By: kwk (kwk) 2011-04-26 03:19:44

Maybe I should mention that with the current configuration ("directmedia=yes") the calling parties don't hear each other. When "directmedia" is set to "no" they can hear each other.

By: Leif Madsen (lmadsen) 2011-04-26 08:04:08

Using ASCII, do I understand this right?

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

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.



By: kwk (kwk) 2011-04-26 09:12:52

@lmadsen: Yes, I've tried directrtpsetup=yes with directmedia=yes and directmedia=no on both nodes. With directrtdpsetup=yes and directmedia=no the calling and called party can hear each other but the traffic travels through the asterisk nodes.

With directrtpsetup=yes and directmedia=no the parties cannot hear each other.

With directrtpsetuo=no and directmedia=yes it is the same: they cannot hear each other.

In fact, I'm monitoring the traffic and can create flow charts that protocol the SIP calls. Before I can post these images I must first put one asterisk node on a different machine with a different network interface. Otherwise the two asterisk nodes won't communicate over the switch which I'm monitoring. Ah, for the time being I will attach the chart I have right now. But keep in mind that these charts won't show any communication between the asterisk nodes.



By: kwk (kwk) 2011-04-26 09:17:54

For the time being, please see the "directmedia-yes.png" file for how the telephones communicate with the asterisk servers. The asterisk servers themselves are communicating on a bridge invisible to my monitoring solution. I will fix this and come back with an updated image.

By: kwk (kwk) 2011-04-26 10:33:47

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".

By: Michael Spiceland (mspiceland) 2011-08-25 09:50:22.105-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:00.866-0500

This is supposed to be closed per the commit message.