[OpenSIPS-Users] Need help with nathelper & rtpproxy (or mediaproxy if it would work better) - how to configure scenarios, and noted "bug"

[Kirk Stephens]

Hello all,

 

 

I am trying to understand how to configure nathelper and rtpproxy to do media hairpinning to the OpenSIPs proxy between two call legs in  the following 3 scenarios.  I have all of the signal routing working as desired, and I have been able to directly connect media between clients and the PSTN gateways, however, I need to find a way to hairpin on the OpenSIPs rtpproxy directly, I am just trying to understand how I can hairpin and exchange the media between the two call legs on the public side of the OpenSIPs proxy.  I have been working with rtpproxy so far.  If this would be easier accomplished with media proxy please point me in the right direction.  Also, if anyone is aware of a problem in  that supporting all three scenarios  here is beyond the design scope for an OpenSIPs solution (and I need to look at B2BUA purpose-built options instead) please let me know (and maybe recommend a Free Open Source B2BUA solution you have had any positive experience with).

 

 

Scenario 1: NAT client termination to PSTN

 

Nat'd Client UAC  à  OpenSIPS Public Int à AppServer w/ private IP (think of something like asterisk here)  = Leg 1.

AppServer w/private IP à OpenSIPS Private Int à Public PSTN GW = Leg 2

 

 

With end result being media flow as:

 

Nat'd Client UAC media à OpenSIPS/SER public Int à Public PSTN GW  - and

Public PSTN GW à OpenSIPS/SER public Int à Nat'd Client UAC pinhole

 

 

Note:  The appserver in this case uses the same SDP parameters to start Leg 2 as it received from OpenSIPS on Leg1, but generates a different call id.

 

 

Scenario 2:  PSTN Origination to NAT clients

 

PSTN GW à OpenSIPS/SER Public Int à AppServer  w/ private IP = Leg 1.

AppServer w/ Private IP à OpenSIPs Private Int à Nat'd client UAS pinhole = Leg 2.

 

With the same result media flow as:

 

Nat'd Client UAC media à OpenSIPS/SER public Int à Public PSTN GW  - and

Public PSTN GW à OpenSIPS/SER public Int à Nat'd Client UAS pinhole

 

Note:  The appserver in this case uses the same SDP parameters to start Leg 2 as it received from OpenSIPS on Leg1, but generates a different call id.

 

 

Scenario 3:  PSTN or NAT clients directly to AppServer

 

(PSTN GW ||  Nat'd Client) à OpenSIPS/SER Public Int à AppServer w/ Private IP.

 

With the media flow as:

 

(PSTN GW ||  Nat'd Client) à OpenSIPS/SER Public Int à AppServer w/ Private IP.

AppServer w/ Private IP à OpenSIPS/SER Public Int à (PSTN GW || Nat'd Client --- same  one as is sending audio).

 

Note:  The appserver in this case responds with its local address/port as the connection info parameter in SDP.

 

 

 

Noted "bug"

 

I am not sure if this is a "bug" or not, but the "nortpproxy" string, if left to default, or set to anything other than a blank string, has consistently been prepended with a null character.  I have seen this in wireshark on various legs of various calls wherever it inserts the custom SDP attribute.  This causes problems with my appserver, and it will not process the message because of the null character.  Because of this, I have had to disable the norttpproxy parameter with 'modparam("nathelper", "norrtpproxy_str", "")'.   If it is necessary to actually set this to achieve the above, is there known workaround to preventing the null character from being prepended to the attribute line?

 

 

 

 

Kirk Stephens

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20081028/8dd8e57f/attachment-0001.htm