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