<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I too am seeing this...... using the same version (behavior didn't
change when mediaproxy was upgraded from 1.2 to 1.4.2).<br>
<br>
The symptom (which I believe has a similar root cause) is the a client
which issues two re-invites (a 'hold' and 'unhold') looses it's audio.
The unhold message moves the local RTP port to a different location and
the mediaproxy seems to ignore the new local destination port and
continues to send media to the 'old' (now orphaned) port.<br>
<br>
Invite (client->proxy)<br>
(with sdp) 1.2.3.4:900 <br>
<br>
OK (proxy->client)<br>
(with sdp) 5.6.7.8:3500<br>
<br>
ReInvite (client->proxy)<br>
(with sdp) 1.2.3.4:1200<br>
<br>
OK (proxy->client)<br>
(with sdp 1.2.3.4:3500<br>
<br>
[Proxy continues to deliver RTP to client at port 900]<br>
<br>
Thanks for any help<br>
<br>
Jim<br>
<br>
<br>
<br>
Joel Rosenfield wrote:
<blockquote cite="mid20051115163100.18504.qmail@web60421.mail.yahoo.com"
type="cite">
<pre wrap="">As I am new to this list, please tell me if there is a more appropriate list to
which I should post this question.
Does the mediaproxy handle changes in the media description within the same
call dialog? If not, are there plans to do so?
Here is what I have done:
I am using the SER mediaproxy module v1.4.2 and a co-located proxydispatcher
and mediaproxy to accomplish NAT traversal between a 3PCC and an remote ATA.
All basic call scenarios work fine. However, when the module receives a
reINVITE to reconnect the ATA to a different party, the mediaserver fails to
forward the RTP packets between the ATA and party described in the new SDP.
I saw in the mediaproxy logs that RTP packets had been received from both
sides, but the signIn method was being invoked as "called" for both parties.
I explored the rtphandler.py and saw that the "catchall" clause at the end of
RTPStream.handle_read was being invoked as you can see by the debug statement
that I added to the code. It appears that this is invoked because both parties
had already signed in based upon the previous media description, so none of the
other mapping/forwarding clauses are invoked.
It seems that there needs to be a mechanism to clear the mappings when the
mediaproxy receives a "request" command for the same session (based upon the
SIP Call-ID) but a new SDP. I got it work by adding code to the beginning of
RTPSession.updateStreams() that clears the list "mediaStreams" and letting the
rest of the code in that method recreate the mappings from scratch. See the
attached file containing the code, a mediaproxy log before the change, and a
log from after the change.
Although this works, the solution is a bit incomplete since it can cause brief
interruptions in the RTP stream when a reINVITE is received that does not
include an SDP change, etc.
Please let me know if there is something I am missing with respect to how I
should using the mediaproxy.
Thanks,
- Joel Rosenfield
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
<a class="moz-txt-link-freetext" href="http://farechase.yahoo.com">http://farechase.yahoo.com</a></pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Serusers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:serusers@lists.iptel.org">serusers@lists.iptel.org</a>
<a class="moz-txt-link-freetext" href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>
</pre>
</blockquote>
</body>
</html>