Re: [OpenSER-Users] "200 OK" not SDP fixed by RtpProxy... but it works ! ¿?

[Daniel-Constantin Mierla]

Hello,

some user agents are configured to send rtp to the address and port from 
where they receive rtp (so called co-media support). It is an 
explanation that can be there. I see no other reason, if the media IP is 
not changed.

Cheers,
Daniel


On 10/17/07 15:27, Iñaki Baz Castillo wrote:
> Hi, user_A with STUN calls to user_B behind NAT with no STUN.
>
> onreply_route[1] {
>     if (nat_uac_test("1"))
>         fix_nated_contact();
>     if (isbflagset(6) && status=~"(180)|(183)|2[0-9][0-9]")
>         force_rtp_proxy("l");
> }
>
> In the initial request bflag(6) is up because "location" of user_B so RtpProxy 
> is used in the INVITE and 200-OK.
>
> But in re-INVITE bflag(6) is down and is not applied force_rtp_proxy("l"); in 
> the 200-OK.
>
> In fact I debug the SIP trace in the re-INVITE in OpenSer:
>
> ----------------------------------------------------------------------
> # user_A -> OpenSer
> INVITE sip:user_B at 112.121.235.28:5061 SIP/2.0
>   c=IN IP4 212.121.235.18
>
>
> # OpenSer -> user_B
> INVITE sip:806 at 212.121.235.18:5061 SIP/2.0
>   c=IN IP4 80.94.0.110   <---- RtpProxy applied (OK)
>
>
> # user_B -> OpenSer
> SIP/2.0 200 OK
>   c=IN IP4 192.168.1.106  [*1]
>     *1: Needs RtpProxy but bflag(6) is down so not applied.
>
>
> # OpenSer -> user_A
> SIP/2.0 200 OK
>   c=IN IP4 192.168.1.106  <-- RtpProxy NO applied
> ----------------------------------------------------------------------
>
>
> But I can confirm that the audio works after re-INVITE in both directions!!! 
> ¿?
> I've debugged with tcpdump, the RTP is send to RtpProxy from user_A, how is 
> possible??
>
>
> Thanks.
>
>
>