[Serusers] 200 OK/SDP and ACK/SDP problem - 2

[Alexandr Volkov]

Greger,
you are right. But when calling client A with public IP send initial invite 
nat_uac_test will return false, and route header will not be changed.
And when client B respond by OK with nated SDP, mediaproxy will not start 
correctly (it seems that mediapoxy doesn't work when only one SDP 
processed). When we processing INVITE we don't know that we need to start 
mediaproxy.


----- Original Message ----- 
From: "Greger Viken Teigre" <greger at teigre.com>
To: <avolkov at abisoft.spb.ru>
Cc: "SER Users" <serusers at lists.iptel.org>
Sent: Monday, October 22, 2007 2:07 PM
Subject: Re: [Serusers] 200 OK/SDP and ACK/SDP problem - 2


> Alexandr,
> The best way to do this is to record nating in a record-route param. See 
> the Getting Started configs for 0.9.x and  (I think) any example config 
> for 2.0, see
> etc/ dir for ser-oob.cfg or the etc/buildsystem
> g-)
>
> ------- Original message -------
> From: Alexandr Volkov <avolkov at abisoft.spb.ru>
> Sent: 22.10.'07,  10:41
>
>> Hi all
>> I have a problem that correlates with problem that was already posted in 
>> 2006-Feb 
>> (http://lists.iptel.org/pipermail/serusers/2006-February/026841.html)
>>
>> I have a stateful ser with mediaproxy at public IP, client A(SIP B2BUA) 
>> with public address and client B(user phone) with private address.
>> 1. SIP dialog already established and client A send re-invite without SDP 
>> (reinvite is necessary, problem was described in rfc3725.txt).
>> 2. client B respond OK(200) with NATed SDP
>> 3. Client A send ACK with normal SDP.
>>
>> At step 2 in ser we can determine that we need to use media proxy and we 
>> start it.
>> But when we processing ACK, we see normal SDP, and won't to start 
>> mediaproxy. Thus we have one-way audio.
>> I tried to use flags, but it seems that when ACK arrives all flags 
>> zeroed. (Ser imply that ACK don't belong to invite transaction?)
>> I can't use AVP because commands are unavailable in onreply_route. The 
>> only way I found is to use global flags.
>> But this way is worse because foreign ACK can be processed between our OK 
>> and ACK from the same transaction...
>>
>> Thanks for your advise.
>> Alex
>>
>
>
>