[Devel] [ openser-Bugs-1673089 ] bad c= with nathelper and rtpproxy -l

[SourceForge.net]

Bugs item #1673089, was opened at 2007-03-03 11:55
Message generated for change (Comment added) made by brent_thomson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1673089&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Manuel Guesdon (mguesdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: bad c= with nathelper and rtpproxy -l 

Initial Comment:

OpenSer openser-1.1.1-tls (22-Jan-2007 15:03)

I run rtpproxy with -l 1.2.3.36

A sip message containing:
       c=IN IP4 10.250.0.130 
         (10.250.0.130 is the natted network)
is transformed to:
       c=IN IP4 4.5.6.1451.2.3.36
         (4.5.6.145 is the public IP of the natted network).

As far as I understand, 4.5.6.145 is not replaced by 1.2.3.36 but 1.2.3.36 is appended.

I think the problem is in alter_mediaip (in nethelper.c).

Here is some traces:
force_rtp_proxy2: proxy reply: 35046 1.2.3.36

in alter_mediaip: oldip=10.250.0.130 newip is 1.2.3.36
                  oldpf=2 newpf=2
                  oip.s and offset seems ok

in build_res_from_sip_res I see 
      c=IN IP4 4.5.6.1451.2.3.36
just after 
      process_lumps(msg, msg->add_rm, new_buf, &offset, &s_offset, 0);/*FIXME:*/
      process_lumps(msg, msg->body_lumps, new_buf, &offset, &s_offset, 0);


----------------------------------------------------------------------

Comment By: Brent (brent_thomson)
Date: 2007-03-03 13:45

Message:
Logged In: YES 
user_id=1734396
Originator: NO

P.S. The code listed is from lines 1567-8 of msg_translator.c

----------------------------------------------------------------------

Comment By: Brent (brent_thomson)
Date: 2007-03-03 12:39

Message:
Logged In: YES 
user_id=1734396
Originator: NO

I can confirm this is also an issue when using mediaproxy.

Hans Fugal noticed the problem here:
http://hans.fugal.net/blog/articles/2006/02/04/use_media_proxy. He thought
it was due to calling use_media_proxy() twice, which it isn't _really_ but
appears to be since any attempt to change the SDP media address just
prepends the new address, instead of replacing it. You can see the same
effect by calling fix_nated_sdp().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1673089&group_id=139143