I've been happily using the force_rtp_proxy() function, exported from the nathelper module for some time now. Recently, I've added some videophone UA's to our system, and we are finding that rtpproxy is only relaying the audio for sessions between video phones.

Having ran some SIP traces I've noticed that the SDP is not being correctly rewritten. Whilst the contact header for the audio is being allocated a port from rtpproxy's range correctly, the corresponding m= field for the video is not being rewritten at all. I've included an excerpt of the SDP I am seeing below.

v=0 o=1000 16724 16724 IN IP4 192.168.1.66 s=videophone c=IN IP4 openser.ip.address.here t=0 0 a=sendrecv m=audio 35030 RTP/AVP 98 0 8 a=ptime:20 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=20 m=video 5010/1 RTP/SAVPF 99 b=AS:110 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=1;parameter-add=0;sprop-parameter-sets=J0KgHpWgsTk=,KM4Ec Q== a=key-mgmt:key CnNnTdBxKycXpOh/Z6VPdeF1/u3+cVcQzAJAN4dWuGM a=direction:active

RTPproxy's UDP port range is 35000-65000, and as you can see, the m=audio field is rewritten by calling force_rtp_proxy(), with the port value of 35030, but the m=video field retains the port that the UA defines as its starting UDP port for media.

This is the first time I've dabbled with video and SIP, so was hoping someone with more experience might already have hit this problem, before I start delving into the code

I'm running rtpproxy 0.3, and have also tried various other versions of rtpproxy from cvs to no avail.

Any help appreciated.

Cheers, Adam