[Serusers] SEMS & mediaproxy

Jan Janak jan at iptel.org
Fri May 28 16:33:07 CEST 2004


First of all, there is no need to use rtpproxy when one side of the
dialog is SEMS in the public internet (which, I believe, is the case
here). SEMS implements the symmetric RTP extensions, all you have to do
is make sure that there is a=direction:active flag in the SDP when the
callee is behind NAT. You do not have to rewrite IPs at all, because in
this case SEMS will wait for the first RTP packet and send RTP packets
there instead of the IP from SDP.

That means, do not call use_media_proxy when forwarding to SEMS. Make
sure that SDP contains the flag mentioned above when forwarding to SEMS.

  Jan.

On 26-05 10:27, Ezequiel Colombo wrote:
> I have problems with sems and SER+mediaproxy
> When i send a call to sems for voicemail the SDP content received by sems have the c= line with the private address of caller. Before send the call to sems my SER use mediaproxy to fix nat problems, but sems dont receive the SDP changed and the RTP generated by SEMS is sent to the wrong ip address.
> 
> -- on my ser.cfg --
>         if (method=="INVITE") {
>            log(1,"ROUTE_0: INVITE METHOD\n");
> 
>            if (!search("^Record-Route:")) {
>               log(1,"ROUTE_0: Use Mediaproxy");
>               use_media_proxy();
>            };
> ...
>         log(1,"ROUTE_1: ARCOTEL-TO-ARCOTEL ");
>         lookup("aliases");
>         if (!lookup("location")) {
>            log(1, "ROUTE_1: USER OFFLINE OR INVALID\n");
>            route(8);
>            break;
>         };
> ...
> route[8] {
>        log(1,"ROUTE_8: VOICEMAIL");
>         if (!t_newtran()) { sl_reply_error(); break; };
>         use_media_proxy();
>         t_reply("183","Conectandose");
> 
>         if(!vm("/tmp/am_fifo","voicemail")){
>            log(1,"could not contact voicemail\n");
>            t_reply("500","could not contact voicemail");
>         };
> break;
> }
> 
> -- on my ser.cfg --
> 
> -- on syslog file --
> May 26 10:13:17 billing /usr/sbin/ser[9814]: ROUTE_1: ARCOTEL-TO-ARCOTEL
> May 26 10:13:17 billing /usr/sbin/ser[9814]: ROUTE_1: USER OFFLINE OR INVALID
> May 26 10:13:17 billing /usr/sbin/ser[9814]: ROUTE_8: VOICEMAIL
> May 26 10:13:17 billing proxydispatcher[9919]: command request 3B48F4D2-CB2B-42B2-80AD-F5064BC02868 at 10.10.0.29 10.10.0.29:800
> 0 200.80.35.6 arcotel.net local arcotel.net local X-Lite=20release=201103a flags=
> May 26 10:13:17 billing proxydispatcher[9919]: domain arcotel.net doesn't define any mediaproxy.
> May 26 10:13:17 billing proxydispatcher[9919]: will use default mediaproxy for this call.
> May 26 10:13:17 billing mediaproxy[25721]: command request 3B48F4D2-CB2B-42B2-80AD-F5064BC02868 at 10.10.0.29 10.10.0.29:8000 20
> 0.80.35.6 arcotel.net local arcotel.net local X-Lite=20release=201103a flags=
> May 26 10:13:17 billing proxydispatcher[9919]: forwarding to mediaproxy on /var/run/mediaproxy.sock: got: 'public.ip.proxy 35062
> May 26 10:13:17 billing /usr/sbin/ser[9812]: ROUTE_0: Fixing Contact
> May 26 10:13:17 billing /usr/sbin/ser[9812]: ACK
> May 26 10:13:17 billing /usr/sbin/ser[9812]: END ROUTE_0 - RELAY
> May 26 10:13:27 billing /usr/sbin/ser[9839]: ROUTE_0: Fixing Contact
> May 26 10:13:27 billing /usr/sbin/ser[9839]: BYE
> -- on syslog file --
> 
> -- on SEMS trace --
> ...
> (9780) DEBUG: execute (AmServer.cpp:277): body: `v=0
> o=ecolombo 2205701 2205771 IN IP4 10.10.0.29
> s=X-Lite
> c=IN IP4 10.10.0.29
> t=0 0
> m=audio 8000 RTP/AVP 3 0 101
> a=rtpmap:0 pcmu/8000
> a=rtpmap:3 gsm/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> ...
> (9920) DEBUG: setRAddr (AmRtpStream.cpp:333): RTP remote address set to 10.10.0.29:8000
> (9920) DEBUG: negotiate (AmSession.cpp:150): Sending Rtp data to 10.10.0.29/8000
> ...
> -- on SEMS trace --
> 
> Thanks
> Ezequiel Colombo

> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers




More information about the sr-users mailing list