25 Apr
2006
25 Apr
'06
1:53 p.m.
thanx,
dev version of nathelper works correctly.
Antanas
----- Original Message -----
From: "Klaus Darilion" <klaus.mailinglists(a)pernau.at>
To: "Antanas Masevicius" <admin(a)ntt.lt>
Cc: <users(a)openser.org>
Sent: Tuesday, April 25, 2006 10:45 AM
Subject: Re: [Users] changing SDP session and media attributes in 200 OK
Antanas Masevicius wrote:
Hello,
i am using rtpproxy with openser to act as a RTP bridge to IP-SS7
gateway. IP-SS7 GW should not be exposed to external clients directly.
Architecture diagram is like this:
|UA1|--SIP/RTP---|
|------------------| |-----------| |
OpenSer+RTPProxy | --SIP/RTP-- | IP-SS7-GW |
|------------------| |-----------|
|UA2|--SIP/RTP---|
Problem is when i try to send fax RTP packets destined for UA2 from
IP-SS7 GW are sent directly.
They should go through RTPProxy, otherwise media ports does not match.
onreply route looks like:
onreply_route[1] {
if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
fix_nated_contact();
}
force_rtp_proxy();
}
each request is record_route()'ed before it is sent to be routed back
through proxy.
I noticed that OpenSer removes top most via header in 200 OK messages:
This is fine - when relaying a request each hop adds a Via header. When
relaying responses, each hop removes the Via header which he added to the
request.
200 OK message for re-Invite received by
OpenSer:
SIP/2.0 200 OK\r\n
From: <sip:870000049@sp2.ntt.lt>;tag=4fbb0552\r\n
To: <sip:70000050@sp2.ntt.lt>;tag=0-13c4-444c9fc6-f4eac-fdd\r\n
Call-ID: cc36b0-0-13c4-444c9fc6-f4eac-2c87(a)sp2.ntt.lt\r\n
<mailto:cc36b0-0-13c4-444c9fc6-f4eac-2c87@sp2.ntt.lt\r\n>
CSeq: 666497904 INVITE\r\n
Via: SIP/2.0/UDP 84.32.0.18;branch=z9hG4bKf67f.2aeace41.0\r\n
Via: SIP/2.0/UDP 84.32.0.7:5060;branch=z9hG4bK444cbbfca6214604dc9\r\n
Supported: 100rel\r\n
User-Agent: SIP-RG\r\n
Contact: <sip:70000050@84.32.134.143>\r\n
Content-Type: application/sdp\r\n
Content-Length: 317\r\n
\r\n
v=0\r\n
o=SIP-N-TA 0 0 IN IP4 84.32.134.143\r\n
s=5420868F 0000 5420868F 0000 01 0\r\n
c=IN IP4 84.32.134.143\r\n
t=0 0\r\n
m=image 4008 udptl t38\r\n
c=IN IP4 84.32.134.143\r\n
a=T38FaxVersion:0\r\n
a=T38MaxBitRate:14400\r\n
a=T38FaxFillBitRemoval:0\r\n
a=T38FaxTranscodingMMR:0\r\n
a=T38FaxTranscodingJBIG:0\r\n
a=T38FaxRateManagement:transferredTCF\r\n
200 OK message sent to IP-SS7 GW by OpenSer:
SIP/2.0 200 OK
From: <sip:870000049@sp2.ntt.lt>;tag=4fbb0552
To: <sip:70000050@sp2.ntt.lt>;tag=0-13c4-444c9fc6-f4eac-fdd
Call-ID: cc36b0-0-13c4-444c9fc6-f4eac-2c87(a)sp2.ntt.lt
<mailto:cc36b0-0-13c4-444c9fc6-f4eac-2c87@sp2.ntt.lt>
CSeq: 666497904 INVITE
Via: SIP/2.0/UDP 84.32.0.7:5060;branch=z9hG4bK444cbbfca6214604dc9
Supported: 100rel
User-Agent: SIP-RG
Contact: <sip:70000050@84.32.134.143>
Content-Type: application/sdp
Content-Length: 333
v=0
o=SIP-N-TA 0 0 IN IP4 84.32.134.143
s=5420868F 0000 5420868F 0000 01 0
c=IN IP4 84.32.134.143
t=0 0
m=image 39246 udptl t38
c=IN IP4 84.32.0.18
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=nortpproxy:yes
In this message there is no indication that is came from SIP proxy (no
record-route, no via header), then IP-SS7 GW sends ACK message directly.
For in-dialog requests Record Route is not necessary, as the route set is
constructed from the Record-Route headers in the initial INVITE. Even if
there would be Record Route headers the clients must not use them. Maybe
one of your clients is buggy and constructs the route set after each
in-dialog request new.
This, i suppose, is normal thing, is it? Problem
is that IP-SS7 also
sends RTP traffic to UA2 directly. This probably happens because of two
'c=' fields in SDP.
Sounds obvious. AFAIK there was recently a patch on the mailinglist which
added a feature to modify all c= lines.
regards
klaus
> OpenSer changes only one in media part. Is there a way to change 'c='
> field in SDP not only on media part?
> Which should take precedence if both can't be changed?
> regards,
> Antanas Masevicius
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users