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:[EMAIL PROTECTED]>;tag=as226ce7b9.
 > To: <sip:[EMAIL PROTECTED]:5062>;tag=3123AAA8-20C5.
 > Date: Tue, 11 Apr 2006 09:10:29 GMT.
 > Call-ID: [EMAIL PROTECTED]
 > Server: Cisco-SIPGateway/IOS-12.x.
 > CSeq: 102 INVITE.
 > Allow-Events: telephone-event.
 > Contact: <sip:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]>;tag=as1a2f900d.
 > To: <sip:[EMAIL PROTECTED]:5062>;tag=3121D1B4-1BFD.
 > Date: Tue, 11 Apr 2006 09:08:28 GMT.
 > Call-ID: [EMAIL PROTECTED]
 > Server: Cisco-SIPGateway/IOS-12.x.
 > CSeq: 102 INVITE.
 > Allow-Events: telephone-event.
 > Contact: <sip:[EMAIL PROTECTED]: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
 > [email protected]
 > http://openser.org/cgi-bin/mailman/listinfo/users
 >




_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users

Reply via email to