Hi Jeff, On 16 Jul 2009, at 00:37, Jeff Pyle wrote:
> We're interfacing this Opensips + Mediaproxy with an existing > system. We > cannot change the existing system. Eventually this system will > contain > NAT'ed clients, hence the Mediaproxy. I didn't want to introduce > NAT until > everything was working properly without it. > > I'll try the use_media_proxy() method and see what happens. > > > - Jeff > > > On 7/12/09 5:28 AM, "Olle E. Johansson" <[email protected]> wrote: > >> On a different note, why keep asterisk re-invites turned on if you >> use >> a media proxy in the call? >> Re-invites are best used when no NAT or firewall support is needed, >> and since you're using media proxy, it indicates to me that you might >> not want to have re-invites turned on at all. >> >> /O I've just been scrutinizing your SIP trace, as you still haven't provided me with mediaproxy-relay debug output. What happens when the SDP offerer comes with a new ip/port combination for a particular stream is that mediaproxy allocates a new set of ports for this internally. You can see that this happens by the fact that for the re- invite, the RTP port in the modified SDP is different. This means that both endpoints actually should start sending to a new destination as a result of the re-INVITE exchange. If they do, the previous RTP exchange and the next one can never actually "cross wires". Now I'm not exactly sure what your problem is, as you said before it's PSTN -> SIP phone that is giving you trouble, yet you've included a trace which seems to be in the opposite direction. Again, please include a media-relay log and describe what you are (not) hearing at either endpoint. Ruud Klaver AG Projects _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
