Hi,
So I was experimenting with OpenSIPS 1.7.2 specifically with processing a
PUBLISH request from a SIP UA that was being NAT'd (the client's source IP and
Port were being NAT'd) and OpenSIPS is NOT aware of the NAT. The UA is
normally connected to an Asterisk based PBX and doesn't normally have direct
access to OpenSIPS (OS is used at the edge as an SBC)--so the PUBLISH to
OpenSIPS is the only method the client UA uses to communicated with OpenSIPS
directly.
So rather than try and deal with NAT in a more traditional OpenSIPS sort of way
directly, I thought it might be super simple to just rewrite the received port
($rp) for the reply using the value of the original request's sender port ($sp)
then send a reply back to the UA via t_reply.
It seems however that OpenSIPS does not want to reply back on the same port
that the connection was received from by OpenSIPS (for example if source IP ==
87.180.156.186 and source port = 1032, OpenSIPS should just send the 200 OK
reply back to the same source IP and $rp port that I manually set? I doesn't
seem to work instead OpenSIPS reply's back to the original $si but on port 5060
which I can only guess is coming from the port in the VIA or maybe contact
headers?
Any suggestions or ideas of what I am doing wrong?
Here's my sample routing block:
route {
[snip]
if (is_method("PUBLISH"))
{
xlog("L_INFO", "PUBLISH Received (sp): $sp");
xlog("L_INFO", "PUBLISH Received (rp): $rp");
$rp = $sp;
xlog("L_INFO", "PUBLISH Received (new rp): $rp");
route(2);
}
[snip]
}
route[2]
{
if (!t_newtran())
{
sl_reply_error();
exit;
};
if(is_method("PUBLISH"))
{
xlog("L_INFO", "route[2] (rp): $rp");
t_reply("200","PUBLISH RECEIVED");
exit;
}
}
Output from opensips.log:
Jul 25 14:36:02 HCVSBC01 /usr/sbin/opensips[9829]: PUBLISH Received (sp): 1032
Jul 25 14:36:02 HCVSBC01 /usr/sbin/opensips[9829]: PUBLISH Received (rp): 5060
Jul 25 14:36:02 HCVSBC01 /usr/sbin/opensips[9829]: PUBLISH Received (new rp):
1032
Jul 25 14:36:02 HCVSBC01 /usr/sbin/opensips[9829]: route[2] (rp): 1032
ngrep of the original SIP request and the OpenSIPS reply:
U 2013/07/25 14:36:02.875908 87.180.156.186:1032 -> 67.203.110.1:5060
PUBLISH sip:67.203.110.1:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.253.82:5060;branch=z9hG4bK6a4204a58A1FFC74.
From: "555-1234" <sip:[email protected]>;tag=634E87BF-917454FE.
To: <sip:67.203.110.1:5060>.
CSeq: 1 PUBLISH.
Call-ID:
[email protected]<mailto:[email protected]>.
Contact: <sip:[email protected]:5060>.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY,
PRACK, UPDATE, REFER.
Event: vq-rtcpxr.
User-Agent: PolycomSoundPointIP-SPIP_550-UA.
Accept-Language: en.
Max-Forwards: 70.
Expires: 3600.
Content-Type: application/vq-rtcpxr.
Content-Length: 628.
.
VQIntervalReport.
LocalMetrics:.
TimeStamps:START=2013-07-25T07:16:34Z STOP=2013-07-25T07:16:38Z.
SessionDesc:PT=0 PPS=50 SSUP=off.
CallID:[email protected]:5060.
LocalAddr:IP=192.168.253.82 PORT=2224 SSRC=1941709243.
RemoteAddr:IP=67.203.110.11 PORT=14570 SSRC=330789935.
JitterBuffer:JBA=3 JBR=5 JBN=30 JBM=60 JBX=160.
PacketLoss:NLR=0.0 JDR=0.0.
BurstGapLoss:BLD=0.0 BD=0 GLD=0.0 GD=4710 GMIN=16.
Delay:RTD=0 ESD=61 IAJ=3.
Signal:RERL=127.
QualityEst:RLQ=93 RCQ=92 MOSLQ=4.1 MOSCQ=4.1.
DialogID:[email protected]:5060;to-tag=as1516977a;from-tag=CED3BAF2-202B2F79.
U 2013/07/25 14:36:02.930303 67.203.110.1:5060 -> 87.180.156.186:5060
SIP/2.0 200 VQ PUBLISH RECEIVED.
Via: SIP/2.0/UDP
192.168.253.82:5060;received=87.180.156.186;branch=z9hG4bK6a4204a58A1FFC74.
From: "555-1234" <sip:[email protected]>;tag=634E87BF-917454FE.
To: <sip:67.203.110.1:5060>;tag=155c340f586c28d0300cf5a6ccf90d99-db4c.
CSeq: 1 PUBLISH.
Call-ID:
[email protected]<mailto:[email protected]>.
Server: OpenSIPS.
Content-Length: 0.
.
Thanks in advance.
Cheers,
JPS
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
