Hi,
I was having a few issues with mediaproxy when it came to re-invites and call setup where the SDP does not get sent with the first INVITE. I noticed this was due a couple couple of assumptions in mediaproxy which don't always hold:
1) That SDP is always set up first by the caller (i.e. in the INVITE) then updated by the called party (i.e. in the 200). This is not the case. The first SDP can be sent in the 200 response by the called party and the caller send their SDP in the ACK. 2) That RTP streams don't change once set up. This is wrong for reINVITEs.
This would cause problems when a user agent sent a reINVITE to redirect RTP to on hold music for example - the RTP change would be ignored. I think this had an impact on some fax setups as well, but I haven't tested it. I found a patch to fix this by storing the streams in a hash by media type, but that is a limiting assumption also (maybe I want 2 audi streams?).
The attached patch fixes this by changing the following:
1) This pathc allows a mediaproxy RTPSession to be set up by either the caller or called party. A 'caller' argument is passed to the RTPSession functions telling it if the caller or called party is doing the setup or update.
2) The official mediaproxy does not even look at SDP details for streams which are already set up. This patch lets every SDP packet update all of the RTP streams for that party (either caller or called).
If you have issues with one-way-audio with media proxy after reINVITEs, have calls the first SDP from the called party or are just plain adventurous, please give it a go. It has been used in a production environment for a bit over a month now. The patch was made against mediaproxy 1.7.2, but will work against 1.8.0 as well since none of the rtphander.py code changed.
Regards, Jeff