[Serusers] how to catch in-dialog INVITEs to NATed user?

Klaus Darilion klaus.mailinglists at pernau.at
Tue Mar 23 11:36:45 CET 2004


Jiri Kuthan wrote:
> 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.

Ok, therefore i would have to use "unstable" branch - say goodbye to 
stable :-(

> 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




More information about the sr-users mailing list