23 Mar
2004
23 Mar
'04
3:04 a.m.
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)?
regards,
Klaus
23 Mar
23 Mar
10:53 a.m.
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)?
You can use "forced lookup" feature available in newest versions of
nathelper/rtppoxy. When force_rtp_prpxy is called with the `l' flag, it
only rewrites SDP and causes the session go through RTP proxy if session
with such id already exists in the proxy.
-Maxim
11:55 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
12:36 p.m.
Jiri Kuthan wrote:
At 02:04 AM 3/23/2004, Klaus Darilion wrote:
Ok, therefore i would have to use "unstable" branch - say goodbye to
stable :-(
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.
How can I do this? Can I add an header which will be present in further
requests? The only header i know to do this is the Record-Route header.
So I would had to add a parameter to the record-route header, and verify
if this tag is present in the Route-header of reINVITEs - would that work?
klaus
7553
days inactive
7553
days old
3 comments
3 participants
participants (3)
-
Jiri Kuthan -
Klaus Darilion -
Maxim Sobolev