11 Apr
2006
11 Apr
'06
11:47 a.m.
Hi,
I've got a gateway which is only used for rounting and rtp proxying between providers
and centrexes.
On reply to an INVITE, one of our provider send back a "183 Session Progress".
The problem is that in the SDP block, we've got 2 media IP address and
rtpproxy only rewrite one.
Finally, the provider establish rtp session with our gateway, and our centrex directly
with the provider.
provider gateway centrex
172.16.0.10 192.168.1.10 192.168.1.20
RTP -------------> RTP ------------> RTP
^-------------------------------------------------|
So my questions are, is it possible to have multiple IP address in SDP and if so, how can
I tell rtpproxy to rewrite all of them.
Coming from provider:
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bKdd67.a4cc2c44.0,SIP/2.0/UDP
192.168.1.20:5062;branch=z9hG4bKdd67.08f45a33.0,SIP/2.0/UDP
192.168.1.20:5060;branch=z9hG4bK4af242b7.
From: "02" <sip:0143132445@192.168.1.20>;tag=as226ce7b9.
To: <sip:0123456789@192.168.1.20:5062>;tag=3123AAA8-20C5.
Date: Tue, 11 Apr 2006 09:10:29 GMT.
Call-ID: 079ab6663e403ff44a1107e5111b075f(a)192.168.1.20.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow-Events: telephone-event.
Contact: <sip:677238#0123456789@172.16.0.10:5060>.
Record-Route:
<sip:192.168.1.10;ftag=as226ce7b9;lr=on>,<sip:192.168.1.20:5062;ftag=as226ce7b9;lr=on>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 3448 4768 IN IP4 172.16.0.10.
s=SIP Call.
c=IN IP4 172.16.0.10.
t=0 0.
m=audio 18322 RTP/AVP 18 101.
c=IN IP4 172.16.0.10.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
Forwarded to centrex:
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP 192.168.1.20:5062;branch=z9hG4bK43a4.3e96aba3.0,SIP/2.0/UDP
192.168.1.20:5060;branch=z9hG4bK3213db83.
From: "02" <sip:0143132445@192.168.1.20>;tag=as1a2f900d.
To: <sip:0123456789@192.168.1.20:5062>;tag=3121D1B4-1BFD.
Date: Tue, 11 Apr 2006 09:08:28 GMT.
Call-ID: 08467c5e299ab833106517c63d3edc2e(a)192.168.1.20.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow-Events: telephone-event.
Contact: <sip:677238#0123456789@172.16.0.10:5060>.
Record-Route:
<sip:192.168.1.10;ftag=as1a2f900d;lr=on>,<sip:192.168.1.20:5062;ftag=as1a2f900d;lr=on>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 277.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 565 174 IN IP4 172.16.0.10.
s=SIP Call.
c=IN IP4 172.16.0.10.
t=0 0.
m=audio 36296 RTP/AVP 18 101.
c=IN IP4 192.168.1.10.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=nortpproxy:yes.
openser.cfg
(...)
onreply_route[1] {
if (status =~ "(180)|(183)|2[0-9][0-9]") {
fix_nated_contact();
if (!search("^Content-Length:[ ]*0")) {
force_rtp_proxy();
};
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
}
(...)
Best regards,
Nicolas Olivier
11 Apr
11 Apr
2:57 p.m.
Hi Nicolas,
it;s perfectly ok - see the SDP RFC : an SDP may contain a default c= in
the session part; each media section (m=) may contain an ip (c=); if it
doesn't the session c= will be used.
regards,
bogdan
Nicolas Olivier wrote:
Hi,
I've got a gateway which is only used for rounting and rtp proxying
between providers and centrexes.
On reply to an INVITE, one of our provider send back a "183 Session
Progress". The problem is that in the SDP block, we've got 2 media IP
address and rtpproxy only rewrite one.
Finally, the provider establish rtp session with our gateway, and our
centrex directly with the provider.
provider gateway centrex
172.16.0.10 192.168.1.10 192.168.1.20
RTP -------------> RTP ------------> RTP
^-------------------------------------------------|
So my questions are, is it possible to have multiple IP address in SDP
and if so, how can I tell rtpproxy to rewrite all of them.
Coming from provider:
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
192.168.1.10;branch=z9hG4bKdd67.a4cc2c44.0,SIP/2.0/UDP
192.168.1.20:5062;branch=z9hG4bKdd67.08f45a33.0,SIP/2.0/UDP
192.168.1.20:5060;branch=z9hG4bK4af242b7.
From: "02" <sip:0143132445@192.168.1.20>;tag=as226ce7b9.
To: <sip:0123456789@192.168.1.20:5062>;tag=3123AAA8-20C5.
Date: Tue, 11 Apr 2006 09:10:29 GMT.
Call-ID: 079ab6663e403ff44a1107e5111b075f(a)192.168.1.20.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow-Events: telephone-event.
Contact: <sip:677238#0123456789@172.16.0.10:5060>.
Record-Route:
<sip:192.168.1.10;ftag=as226ce7b9;lr=on>,<sip:192.168.1.20:5062;ftag=as226ce7b9;lr=on>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 3448 4768 IN IP4 172.16.0.10.
s=SIP Call.
c=IN IP4 172.16.0.10.
t=0 0.
m=audio 18322 RTP/AVP 18 101.
c=IN IP4 172.16.0.10.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
Forwarded to centrex:
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
192.168.1.20:5062;branch=z9hG4bK43a4.3e96aba3.0,SIP/2.0/UDP
192.168.1.20:5060;branch=z9hG4bK3213db83.
From: "02" <sip:0143132445@192.168.1.20>;tag=as1a2f900d.
To: <sip:0123456789@192.168.1.20:5062>;tag=3121D1B4-1BFD.
Date: Tue, 11 Apr 2006 09:08:28 GMT.
Call-ID: 08467c5e299ab833106517c63d3edc2e(a)192.168.1.20.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow-Events: telephone-event.
Contact: <sip:677238#0123456789@172.16.0.10:5060>.
Record-Route:
<sip:192.168.1.10;ftag=as1a2f900d;lr=on>,<sip:192.168.1.20:5062;ftag=as1a2f900d;lr=on>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 277.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 565 174 IN IP4 172.16.0.10.
s=SIP Call.
c=IN IP4 172.16.0.10.
t=0 0.
m=audio 36296 RTP/AVP 18 101.
c=IN IP4 192.168.1.10.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=nortpproxy:yes.
openser.cfg
(...)
onreply_route[1] {
if (status =~ "(180)|(183)|2[0-9][0-9]") {
fix_nated_contact();
if (!search("^Content-Length:[ ]*0")) {
force_rtp_proxy();
};
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
}
(...)
Best regards,
Nicolas Olivier
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
4:02 p.m.
Hi Bogdan,
Ok, I understand now. But I still encounter the problem because:
- rtpproxy only rewrites the c= from media part (but it should be fine as you said)
despite what a quick look in the rtpproxy code comments say ("We
have to change ports in m-lines, and also change IP addresses in c-lines which can be
placed either in session header (fallback for all medias) or
media description.")
- the centrex (which is an asterisk by the way) take only into account the c= from the
session part, not the one from media part
regards,
Nicolas
Bogdan-Andrei Iancu wrote:
Hi Nicolas,
it;s perfectly ok - see the SDP RFC : an SDP may contain a default c= in
the session part; each media section (m=) may contain an ip (c=); if it
doesn't the session c= will be used.
regards,
bogdan
Nicolas Olivier wrote:
Hi,
I've got a gateway which is only used for rounting and rtp proxying
between providers and centrexes.
On reply to an INVITE, one of our provider send back a "183 Session
Progress". The problem is that in the SDP block, we've got 2 media IP
address and rtpproxy only rewrite one.
Finally, the provider establish rtp session with our gateway, and our
centrex directly with the provider.
provider gateway centrex
172.16.0.10 192.168.1.10 192.168.1.20
RTP -------------> RTP ------------> RTP
^-------------------------------------------------|
So my questions are, is it possible to have multiple IP address in SDP
and if so, how can I tell rtpproxy to rewrite all of them.
Coming from provider:
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
192.168.1.10;branch=z9hG4bKdd67.a4cc2c44.0,SIP/2.0/UDP
192.168.1.20:5062;branch=z9hG4bKdd67.08f45a33.0,SIP/2.0/UDP
192.168.1.20:5060;branch=z9hG4bK4af242b7.
From: "02" <sip:0143132445@192.168.1.20>;tag=as226ce7b9.
To: <sip:0123456789@192.168.1.20:5062>;tag=3123AAA8-20C5.
Date: Tue, 11 Apr 2006 09:10:29 GMT.
Call-ID: 079ab6663e403ff44a1107e5111b075f(a)192.168.1.20.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow-Events: telephone-event.
Contact: <sip:677238#0123456789@172.16.0.10:5060>.
Record-Route:
<sip:192.168.1.10;ftag=as226ce7b9;lr=on>,<sip:192.168.1.20:5062;ftag=as226ce7b9;lr=on>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 3448 4768 IN IP4 172.16.0.10.
s=SIP Call.
c=IN IP4 172.16.0.10.
t=0 0.
m=audio 18322 RTP/AVP 18 101.
c=IN IP4 172.16.0.10.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
Forwarded to centrex:
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
192.168.1.20:5062;branch=z9hG4bK43a4.3e96aba3.0,SIP/2.0/UDP
192.168.1.20:5060;branch=z9hG4bK3213db83.
From: "02" <sip:0143132445@192.168.1.20>;tag=as1a2f900d.
To: <sip:0123456789@192.168.1.20:5062>;tag=3121D1B4-1BFD.
Date: Tue, 11 Apr 2006 09:08:28 GMT.
Call-ID: 08467c5e299ab833106517c63d3edc2e(a)192.168.1.20.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow-Events: telephone-event.
Contact: <sip:677238#0123456789@172.16.0.10:5060>.
Record-Route:
<sip:192.168.1.10;ftag=as1a2f900d;lr=on>,<sip:192.168.1.20:5062;ftag=as1a2f900d;lr=on>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 277.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 565 174 IN IP4 172.16.0.10.
s=SIP Call.
c=IN IP4 172.16.0.10.
t=0 0.
m=audio 36296 RTP/AVP 18 101.
c=IN IP4 192.168.1.10.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=nortpproxy:yes.
openser.cfg
(...)
onreply_route[1] {
if (status =~ "(180)|(183)|2[0-9][0-9]") {
fix_nated_contact();
if (!search("^Content-Length:[ ]*0")) {
force_rtp_proxy();
};
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
}
(...)
Best regards,
Nicolas Olivier
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
4:15 p.m.
Hi,
Nicolas Olivier wrote:
Hi Bogdan,
Ok, I understand now. But I still encounter the problem because:
- rtpproxy only rewrites the c= from media part (but it should be fine
as you said) despite what a quick look in the rtpproxy code comments
say ("We have to change ports in m-lines, and also change IP addresses
in c-lines which can be placed either in session header (fallback for
all medias) or media description.")
yes, the nathelper will change the c= from session header only if it
finds a media section without a local c= (which means the default c=
from session hdr will be used).
- the centrex (which is an asterisk by the way) take
only into account
the c= from the session part, not the one from media part
in the CVS devel there is a flag that force also changing of session c= :
http://openser.org/docs/modules/1.1.x/nathelper.html#AEN275 , the
"c" flag
regards,
bogdan
regards,
Nicolas
Bogdan-Andrei Iancu wrote:
Hi Nicolas,
it;s perfectly ok - see the SDP RFC : an SDP may contain a default c= in
the session part; each media section (m=) may contain an ip (c=); if it
doesn't the session c= will be used.
regards,
bogdan
Nicolas Olivier wrote:
Hi,
I've got a gateway which is only used for rounting and rtp proxying
between providers and centrexes.
On reply to an INVITE, one of our provider send back a "183 Session
Progress". The problem is that in the SDP block, we've got 2 media IP
address and rtpproxy only rewrite one.
Finally, the provider establish rtp session with our gateway, and our
centrex directly with the provider.
provider gateway centrex
172.16.0.10 192.168.1.10 192.168.1.20
RTP -------------> RTP ------------> RTP
^-------------------------------------------------|
So my questions are, is it possible to have multiple IP address in
SDP
and if so, how can I tell rtpproxy to rewrite all
of them.
Coming from provider:
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
192.168.1.10;branch=z9hG4bKdd67.a4cc2c44.0,SIP/2.0/UDP
192.168.1.20:5062;branch=z9hG4bKdd67.08f45a33.0,SIP/2.0/UDP
192.168.1.20:5060;branch=z9hG4bK4af242b7.
From: "02" <sip:0143132445@192.168.1.20>;tag=as226ce7b9.
To: <sip:0123456789@192.168.1.20:5062>;tag=3123AAA8-20C5.
Date: Tue, 11 Apr 2006 09:10:29 GMT.
Call-ID: 079ab6663e403ff44a1107e5111b075f(a)192.168.1.20.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow-Events: telephone-event.
Contact: <sip:677238#0123456789@172.16.0.10:5060>.
Record-Route:
<sip:192.168.1.10;ftag=as226ce7b9;lr=on>,<sip:192.168.1.20:5062;ftag=as226ce7b9;lr=on>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 3448 4768 IN IP4 172.16.0.10.
s=SIP Call.
c=IN IP4 172.16.0.10.
t=0 0.
m=audio 18322 RTP/AVP 18 101.
c=IN IP4 172.16.0.10.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
Forwarded to centrex:
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
192.168.1.20:5062;branch=z9hG4bK43a4.3e96aba3.0,SIP/2.0/UDP
192.168.1.20:5060;branch=z9hG4bK3213db83.
From: "02" <sip:0143132445@192.168.1.20>;tag=as1a2f900d.
To: <sip:0123456789@192.168.1.20:5062>;tag=3121D1B4-1BFD.
Date: Tue, 11 Apr 2006 09:08:28 GMT.
Call-ID: 08467c5e299ab833106517c63d3edc2e(a)192.168.1.20.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 102 INVITE.
Allow-Events: telephone-event.
Contact: <sip:677238#0123456789@172.16.0.10:5060>.
Record-Route:
<sip:192.168.1.10;ftag=as1a2f900d;lr=on>,<sip:192.168.1.20:5062;ftag=as1a2f900d;lr=on>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 277.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 565 174 IN IP4 172.16.0.10.
s=SIP Call.
c=IN IP4 172.16.0.10.
t=0 0.
m=audio 36296 RTP/AVP 18 101.
c=IN IP4 192.168.1.10.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=nortpproxy:yes.
openser.cfg
(...)
onreply_route[1] {
if (status =~ "(180)|(183)|2[0-9][0-9]") {
fix_nated_contact();
if (!search("^Content-Length:[ ]*0")) {
force_rtp_proxy();
};
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
}
(...)
Best regards,
Nicolas Olivier
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
4:51 p.m.
Ok, I may have a look to the csv.
Thanks for the help.
regards,
Nicolas
Bogdan-Andrei Iancu wrote:
Hi,
Nicolas Olivier wrote:
Hi Bogdan,
Ok, I understand now. But I still encounter the problem because:
- rtpproxy only rewrites the c= from media part (but it should be fine
as you said) despite what a quick look in the rtpproxy code comments
say ("We have to change ports in m-lines, and also change IP addresses
in c-lines which can be placed either in session header (fallback for
all medias) or media description.")
yes, the nathelper will change the c= from session header only if it
finds a media section without a local c= (which means the default c=
from session hdr will be used).
- the centrex (which is an asterisk by the way)
take only into account
the c= from the session part, not the one from media part
in the CVS devel there is a flag that force also changing of session c= :
http://openser.org/docs/modules/1.1.x/nathelper.html#AEN275 , the
"c" flag
regards,
bogdan
regards,
Nicolas
Bogdan-Andrei Iancu wrote:
> Hi Nicolas,
>
> it;s perfectly ok - see the SDP RFC : an SDP may contain a default
c= in
> the session part; each media section (m=) may
contain an ip (c=); if it
> doesn't the session c= will be used.
>
> regards,
> bogdan
>
> Nicolas Olivier wrote:
>
> >
> > Hi,
> >
> > I've got a gateway which is only used for rounting and rtp proxying
> > between providers and centrexes.
> >
> > On reply to an INVITE, one of our provider send back a "183 Session
> > Progress". The problem is that in the SDP block, we've got 2
media IP
> > address and rtpproxy only rewrite one.
> >
> > Finally, the provider establish rtp session with our gateway, and
our
> > centrex directly with the provider.
> >
> > provider gateway centrex
> > 172.16.0.10 192.168.1.10 192.168.1.20
> > RTP -------------> RTP ------------> RTP
> > ^-------------------------------------------------|
> >
> > So my questions are, is it possible to have multiple IP address in
> SDP
> > and if so, how can I tell rtpproxy to rewrite all of them.
> >
> > Coming from provider:
> >
> > SIP/2.0 183 Session Progress.
> > Via: SIP/2.0/UDP
> > 192.168.1.10;branch=z9hG4bKdd67.a4cc2c44.0,SIP/2.0/UDP
> > 192.168.1.20:5062;branch=z9hG4bKdd67.08f45a33.0,SIP/2.0/UDP
> > 192.168.1.20:5060;branch=z9hG4bK4af242b7.
> > From: "02" <sip:0143132445@192.168.1.20>;tag=as226ce7b9.
> > To: <sip:0123456789@192.168.1.20:5062>;tag=3123AAA8-20C5.
> > Date: Tue, 11 Apr 2006 09:10:29 GMT.
> > Call-ID: 079ab6663e403ff44a1107e5111b075f(a)192.168.1.20.
> > Server: Cisco-SIPGateway/IOS-12.x.
> > CSeq: 102 INVITE.
> > Allow-Events: telephone-event.
> > Contact: <sip:677238#0123456789@172.16.0.10:5060>.
> > Record-Route:
> >
>
<sip:192.168.1.10;ftag=as226ce7b9;lr=on>,<sip:192.168.1.20:5062;ftag=as226ce7b9;lr=on>.
>
> >
> > Content-Disposition: session;handling=required.
> > Content-Type: application/sdp.
> > Content-Length: 261.
> > .
> > v=0.
> > o=CiscoSystemsSIP-GW-UserAgent 3448 4768 IN IP4 172.16.0.10.
> > s=SIP Call.
> > c=IN IP4 172.16.0.10.
> > t=0 0.
> > m=audio 18322 RTP/AVP 18 101.
> > c=IN IP4 172.16.0.10.
> > a=rtpmap:18 G729/8000.
> > a=fmtp:18 annexb=no.
> > a=rtpmap:101 telephone-event/8000.
> > a=fmtp:101 0-16.
> >
> > Forwarded to centrex:
> >
> > SIP/2.0 183 Session Progress.
> > Via: SIP/2.0/UDP
> > 192.168.1.20:5062;branch=z9hG4bK43a4.3e96aba3.0,SIP/2.0/UDP
> > 192.168.1.20:5060;branch=z9hG4bK3213db83.
> > From: "02" <sip:0143132445@192.168.1.20>;tag=as1a2f900d.
> > To: <sip:0123456789@192.168.1.20:5062>;tag=3121D1B4-1BFD.
> > Date: Tue, 11 Apr 2006 09:08:28 GMT.
> > Call-ID: 08467c5e299ab833106517c63d3edc2e(a)192.168.1.20.
> > Server: Cisco-SIPGateway/IOS-12.x.
> > CSeq: 102 INVITE.
> > Allow-Events: telephone-event.
> > Contact: <sip:677238#0123456789@172.16.0.10:5060>.
> > Record-Route:
> >
>
<sip:192.168.1.10;ftag=as1a2f900d;lr=on>,<sip:192.168.1.20:5062;ftag=as1a2f900d;lr=on>.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 277.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 565 174 IN IP4 172.16.0.10.
s=SIP Call.
c=IN IP4 172.16.0.10.
t=0 0.
m=audio 36296 RTP/AVP 18 101.
c=IN IP4 192.168.1.10.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=nortpproxy:yes.
openser.cfg
(...)
onreply_route[1] {
if (status =~ "(180)|(183)|2[0-9][0-9]") {
fix_nated_contact();
if (!search("^Content-Length:[ ]*0")) {
force_rtp_proxy();
};
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
}
(...)
Best regards,
Nicolas Olivier
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6810
days inactive
6810
days old
4 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
Nicolas Olivier