[Home]

Summary:ASTERISK-03882: [patch] SIP RTP redirect problem after MoH
Reporter:Leif Madsen (lmadsen)Labels:
Date Opened:2005-04-06 23:17:24Date Closed:2008-01-15 15:45:00.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) callonhold.dump
( 1) sip-invite.txt
( 2) reinvite.txt
( 3) reinvite0811.txt
( 4) siptrace.txt
Description:Two SIP phones on the same subnet with Asterisk. Clients are configured in sip.conf with canreinvite=yes so that the RTP stream goes directly between the clients. SIP signaling continues to go through Asterisk.

Phone A places Phone B on hold. It sends an INVITE to Asterisk telling Asterisk to stop sending the RTP stream to Phone A, and INVITE Phone B to Asterisk. The RTP stream then switches from going between Phone A and Phone B, to going between Asterisk and Phone B. At this point Music on Hold is being streamed to Phone B.

After a period of time, Asterisk sends an INVITE to Asterisk with its address in the SDP message asking for RTP again. The INVITE line contains Phone-B-Extension@Asterisk-IP-address with a Contact: header field containing the IP address of Phone A. This is enough information for Asterisk to direct the RTP stream from Phone B to Phone A.

At this point Phone A starts sending its RTP to Phone B directly as expected. However, Asterisk does not tell Phone B to start sending its RTP stream towards Phone A. The RTP stream continues to flow between Phone B and Asterisk, and Asterisk then forwards it towards Phone A, thereby staying in the RTP stream path. This is not the expected/desired behaviour as the clients are configured with canreinvite=yes.

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

I've attached the Ethereal packet trace. I've also attached a text file of the some relevant packets and explained at the top what each of them are doing. Asterisk is not sending an INVITE after packet No. 731 to Phone B stating in the SDP the connection address of Phone A.
Comments:By: Leif Madsen (lmadsen) 2005-04-06 23:20:31

I have to thank Steven Hulshof from the Telecommunications Technology class at Sheridan College for helping to find this bug.

Here is the configuration:

extensions.conf

[phones]
exten => 1301,1,SetMusicOnHold(steve)
exten => 1301,2,Dial(SIP/steve,10)
exten => 1301,3,VoiceMail,u1301
exten => 1301,4,Hangup()
exten => 1301,102,Hangup()

exten => 1302,1,SetMusicOnHold(steve)
exten => 1302,2,Dial(SIP/stevemobile)
exten => 1302,3,Hangup()
exten => 1302,102,Hangup()

sip.conf

[steve]
type=friend
username=steve
secret=welcome
host=dynamic
context=default
canreinvite=yes
callerid= Steve <1301>
mailbox=1301@default
allow=g729
allow=ulaw

[stevemobile]
type=friend
username=stevemobile
secret=welcome
host=dynamic
context=default
callerid=Steve Mobile <1302>
canreinvite=yes
disallow=all
allow=ulaw
allow=gsm
allow=h261
allow=h263
By: twisted (twisted) 2005-05-10 23:30:22

oej: any ideas on how to fix?  I would think it'd be a simple swap of sdp addresses and a packet sent to the opposing device as well, but i'm not the SIP guru :P
By: Olle Johansson (oej) 2005-05-13 14:47:19

twisted: My idea: Let's fix it :-)
By: Mark Spencer (markster) 2005-05-14 19:53:12

I'll need to be able to login to a machine which exhibits this issue and perform debugging in realtime with someone ready to make calls.  find me on IRC.
By: Olle Johansson (oej) 2005-05-16 11:34:35

Added a patch in a separate bug report - ZAP-67 - since I discovered a few missing pieces while trying to understand how the RTP native bridge works and why we see this scenario happening in chan_sip.

I do not believe that tge ZAP-67 patch changes this behaviour, but anyway would like to get a confirmation of that. With this patch, the other end of a bridge gets a notification that it is put on hold through AST_CONTROL_HOLD/UNHOLD. It's up to the receiving channel to handle that.
By: Kevin P. Fleming (kpfleming) 2005-05-16 12:12:43

That's bug ASTERISK-4264290, not 4920 :-)
By: Leif Madsen (lmadsen) 2005-05-16 13:38:22

Unfortunately the lab scenario I had setup is no longer setup. Hopefully I can get access to the lab again and recreate it, but not sure when I'll be able to do that :(
By: Michael Jerris (mikej) 2005-06-18 13:18:06

Is anyone able to re-test on this?
By: Kevin P. Fleming (kpfleming) 2005-06-20 16:47:37

blitzrage has been in Madrid for Astricon, so likely has not had an opportunity to try this out. I'll try to lab it up here and see if I can reproduce it.
By: Leif Madsen (lmadsen) 2005-06-21 06:50:34

Unfortunately the equipment I have here also runs the entire home network and other things and is not easy to change :( One of these days I'm going to have to get another Asterisk server and a switch so that I can lab some of this stuff up.

kpfleming: let me know if you need any help with reproducing it as I have a pretty good idea of how it worked - I think I've provided enough info to reproduce it though.
By: Michael Jerris (mikej) 2005-07-20 19:32:19

bringing this back up, does anyone have a lab they can reproduce this in?
By: Leif Madsen (lmadsen) 2005-07-21 14:43:08

Unfortunately I don't have the computers to build this up... if anyone has the equipment, I can certainly help set it up. Or you could just send computer donations to me so I can build my own lab :)
By: Olle Johansson (oej) 2005-07-24 12:57:17

Leif, I can't repeat this.

Have two SIP phones on the same LAN as asterisk. When phone1 sends re-invite with sdp to 0.0.0.0 asterisk does not send a re-invite to the other side, but starts streaming music directly to the phone2. The phone still sends to the phone1, but now receives audio from phone2. After unhold (a re-invite from phone1 to asterisk), the conversation continues as before without a re-invite.
By: Olle Johansson (oej) 2005-07-24 13:21:45

This patch (disclaimed=yes) adds some debug output to make it easier to see what happens inside the SIP channel.
By: Kevin P. Fleming (kpfleming) 2005-07-25 13:36:47

That patch removes the setting/clearing of SIP_CALL_ONHOLD from the private structure; are you sure that is correct?
By: Olle Johansson (oej) 2005-07-26 00:47:56

According to our conversation, yes. If you try it, you'll see that the channel that sent "hold" will be on hold, while the other channel will not be on hold, since we're playing on hold music to them. Also see comments in related bug reports. I initially added those, but changed my mind ;-)

And yes, the hold business is confusing. We now have a new bug report on it.

Also note that this patch helps debugging this issue, it does not resolve it.
By: Olle Johansson (oej) 2005-08-01 10:55:06

Seems like something happened with RTP redirects and OnHold between 1.0.5 and 1.0.7 according to ASTERISK-3918
By: Michael Jerris (mikej) 2005-08-09 13:16:10

Is anybody able to actually reproduce this?
By: Olle Johansson (oej) 2005-08-11 12:10:11

With this patch, we will issue re-invites after we are put on hold and when we're back.
By: Olle Johansson (oej) 2005-08-12 06:52:15

This patch fixes the problem in ASTERISK-3918 according to a note in that issue.
By: Kevin P. Fleming (kpfleming) 2005-08-22 21:48:22

Committed to CVS HEAD, thanks!
By: Leif Madsen (lmadsen) 2006-01-16 16:12:20.000-0600

I'm reopening this bug because Olle and I will be trying to reproduce this while in class this week. He mentions that the patch he added (and was committed to CVS) actually only added debugging information and didn't resolve the issue :)

More information to come.
By: C F (shmaltz) 2006-01-16 16:27:26.000-0600

Interesting, because I did have a problem with attended xfers (which plays MOH) from Polycom to Polycom when the 3rd caller is Sipura, but not when all 3 are Polycoms.
I then decided to upgrade the firmware on both the Polycom and the Sipura. Since the upgrade I had more trouble, that I would have this problem even without xfers, but I'm using queues (with the ring option), and I did not test it with plain vanila dial, so it could still be the same problem. I have since downgraded to 1.0.10 to see if the problem is there as well, and it is.
So for now I'm doing canreinvite=no.
canreinvite=no interduces a new problem for me which I'm still troubleshooting and is described here:
http://lists.digium.com/pipermail/asterisk-users/2006-January/142251.html
and might make it into another bug one day.
In the meanwhile if more testing is needed please let me know.
This is all with no nat, just a plain simple flat network.
By: Leif Madsen (lmadsen) 2006-01-16 16:32:37.000-0600

Tested this again and was unable to reproduce this time around using 1.2.1. So it doesn't seem to be a problem anymore.

schmaltz: if you really need to comment on this, send me a message on irc. I'm blitzrage -- but from what you say it sounds like a phone problem, and not an Asterisk problem...


By: Leif Madsen (lmadsen) 2006-01-19 16:49:49.000-0600

Reopening requested by shmaltz
By: C F (shmaltz) 2006-01-19 17:26:50.000-0600

I uploaded the file siptrace.txt which includes the CLI output of the following problem:
I'm using a Sipura SPA3000 on IP 192.168.1.101 (SIP/801), and a Polycom 500/501 on 192.168.1.196 (SIP/202).
When a call comes in on the FXO port of the polycom, it goes to a Macro that when calling either Dial or Queue will bridge the 2 calls but the redirect doesn't work, and the Polycom cannot hear the Sipura. In the file you can see how the Sipura is still sending the RTP stream to asterisk which asterisk forwards on to the Polycom, which I guess that the polycom is not accepting (which I think is because it is not expecting asterisk to send it any packets but it's expecting the sipura to), however the stream from the Polycom to the Sipura is not passing thru asterisk, which is how it should work.
I tested all this using SSH, so I wasn't able to produce logs for the next part, but I tested it earlier when I was there. If during this process (when the Polycom can't hear the Sipura), I put the call on Hold and then resume the call everything works fine, and Asterisk is NOT in the path of the stream, but it goes directly from the Sipura to the Polycom and visa versa.
I tried this same thing by dialing from the Polycom to the Sipura and the problem doens't exist (I don't remember if Asterisk stays in the path or not, but by the problem doens't exist I mean that there is 2 way audio), it only happens if/when the Sipura calls Asterisk, and asterisk dials the Polycom.
Here are my configs:

[801]
type=friend
username=801
secret=801pass
host=dynamic
dtmfmode=info;rfc2833
context=othellox
canreinvite=yes;no

[202]
type=friend
username=202
secret=202pass
host=dynamic
mailbox=202@othello
callerid= "Dovid" <202>
dtmfmode=rfc2833
context=othello
accountcode=
setvar=DINTERNAL=1


By: Olle Johansson (oej) 2006-01-26 12:04:43.000-0600

shmaltz: We do need a SIP trace from you to sort this out.

Blitzrage's problem does not exist any more in current chan_sip - we set up a lab to test it last week and could not reproduce it.
By: C F (shmaltz) 2006-01-26 12:20:42.000-0600

oej, I'm running now 1.2.3, and changed the device to a Mediatrix 1204, the problem is different now. In that when first birdging the call it works, but if an attd xfer is initiated (to person C), at the final step (person C with xfered) there is only one way audio. If however the call is put on hold (in this case by person C) in then resumed, the audio works as it should. I will try to get sip trace soon.
This might not be the same problem that this bug is meant to be, but it's the closest I was able to find. With Sipura the call would not work at all, like I reported before.
Thank You.
By: Olle Johansson (oej) 2006-01-26 12:33:20.000-0600

After testing with blitzrage, we agreed that his issue does not exist any more. Shmaltz agreed to open a new bug report with his issues.
By: Leif Madsen (lmadsen) 2007-02-01 18:01:49.000-0600

Wow... after this issue being open for a couple of years, 'file' just fixed it today!!!  Good hustle!
By: Digium Subversion (svnbot) 2008-01-15 15:45:00.000-0600

Repository: asterisk
Revision: 6371

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r6371 | kpfleming | 2008-01-15 15:44:59 -0600 (Tue, 15 Jan 2008) | 2 lines

handle on-/off-hold properly with RTP reinvited streams (issue ASTERISK-3882)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=6371