At 02:04 AM 3/23/2004, Klaus Darilion wrote:
Hi!
I just came along a problem in the following scenario: user with public IP calls a NATed user. The first INVITE causes a lookup("location") which also sets the natflag (usually flag 6).
Then I check if flag 6 is set and will force the RTP proxy if it is set. If the public client sends an in-dialog reINVITE, the reINVITE is processed by the loose_route block and there is no lookup("location") for those request. So, how can I find out that the request will be forwarded to a NATed user (to force the RTP proxy)?
In theory there are several ways to accomplish it, I'm just not sure what is doable with today's variety of rtp proxies ;) Generally, you need to be aware that a session is natted, re-INVITEs bear no sign of that. I recall there was an option in the rtpproxy protocol to take an action only if the session already exists. Then you would pass all re-INVITEs to the rtproxy with this option and it would only process such for which a session exists. Other alternatives which do not take session lookup would be to store the "natted bit" in SIP messages and piggy-back it back and forth and use rtpp only for re-INVITEs with this bit.
-jiri
regards, Klaus
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/