[Serusers] ser-rtpproxy bridge mode and T38

Atif Rasheed atif at burraqtel.com.pk
Fri Oct 28 19:28:07 CEST 2005


reInvites are handled at the end of route block

if(method=="INVITE") {
                setflag(6);
                route(1);
                break;
        }

however this problem has been resolved now. force_rtp_proxy required "r"
as an option. which forces to trust/use ip:port in sdp. 

Thank you for your help and participation.

Atif

On Fri, 2005-10-28 at 06:45 +0200, Greger V. Teigre wrote:
> A reINVITE will be caught here in your config:
>  if (loose_route()) {
>   t_relay();
>  };
> 
> For example see onsip.org NAT mediaproxy script for an example of handling 
> reINVITEs:
>  if (loose_route()) {
> 
>   if (has_totag() && (method=="INVITE" || method=="ACK")) {
> 
>    if (client_nat_test("3") || search("^Route:.*;nat=yes")) {
>     setflag(6);
>     use_media_proxy();
>    };
>   };
> 
>   route(1);
>   break;
>  };
> 
> nat=yes is set by record_routing.
> g-)
> 
> ----- Original Message ----- 
> From: "Atif Rasheed" <atif at burraqtel.com.pk>
> To: "Greger V. Teigre" <greger at teigre.com>
> Cc: <serusers at lists.iptel.org>
> Sent: Thursday, October 27, 2005 09:39 AM
> Subject: Re: [Serusers] ser-rtpproxy bridge mode and T38
> 
> 
> > okey, I got your point that it was difficult to understand. but please
> > tell me know if you understood this setup now or should I elaborate
> > little more.
> > As far as ReInvites are concerned I think they are handled properly.
> > Please go through the attached ethereal trace, You will see SIP
> > signalling is properly handled. ser.cfg is also attached with the email
> >
> > MG(10.0.3.13)------->(10.0.2.14)SSW------->10.0.2.99(ser/rtpproxy)80.255.40.70
> >
> > ser/rtpproxy machine is with two i.e. private and public interfaces.
> >
> >> >> > I have read in RtpProxy that RtpProxy waits for both parties to send
> >> >> > atleast one udp packet and then it fills up both ip:port structures
> >> >> > associated with that call and then it starts relaying.
> >> >>
> >> >> Yes, this is to ensure that the proxy can get through the NATs.
> >> >>
> >> >> > Call Setup is like this:
> >> >> >                --------Media----->
> >> >> > A-Party ----->MG-------->SSW------>SER/RtpProxy------->B-Party
> >> >> >
> >> >> > now only B-Party is sending UDP Packets and Ser/RtpProxy sends them 
> >> >> > to
> >> >> > SSW (signalling entity) instead of MediaGateway. As soon as RtpProxy
> >> >> > receives one udp packet from A-Party then it sends those RTP packets 
> >> >> > to
> >> >> > MG i.e. it starts relaying following the right path.
> >> >> > how I can solve this ???
> >> >>
> >> >> I'm afraid I'm not capable of understanding what you are saying here.
> >> >> You
> >> >> have SSW in the media path? Or are you trying to show both media and
> >> >> signalling path in the same picture? What is really the priblem? 
> >> >> rtpproxy
> >> >> will only do what you tell it to (using force_rtp_proxy).
> >> >
> >> > I am trying to show media and signalling path in the same picture.
> >>
> >> I'm sure you understand that it is difficult for others to understand?
> >>
> >> > Is this confirm that RtpProxy will handle T38 or we also need to handle
> >> > T38 in a special way. because as I described below paragraph that after
> >> > reinvite B-Party stopped RTP and started T38 packets in the same 
> >> > session
> >> > but RtpProxy failed to send to the right recepient.
> >>
> >> It's not T38 that needs special handling, but as I said, the reINVITE.
> >> g-)
> >> >>
> >> >> > Adding to this, now after RTP relay starts successfully. B-Party (if
> >> >> > Dialed number is a FAX) reinvites with T38 and the IP:Port info in 
> >> >> > SDP
> >> >> > remains same. Now somehow RtpProxy is not recognizing the T38 
> >> >> > packets
> >> >> > becuase we are in the same session and RtpProxy start sending those
> >> >> > T38 packets to SSW (signalling entity) instead of sending to MG. 
> >> >> > Please
> >> >> > remember we are in the same session, and RtpProxy shud send these 
> >> >> > T38
> >> >> > packets to MG, as it was sending RTP packets before ReInvite.
> >> >> >
> >> >> > is it a bug in RTPProxy, should I use MediaProxy instead ???
> >> >>
> >> >> You need to handle reINVITEs in a special way. Look at the Getting
> >> >> Started
> >> >> scripts (and document) from onsip.org for how to do it both for 
> >> >> rtpproxy
> >> >> and
> >> >> mediaproxy.
> >> >>
> >> >> g-)
> >> >>
> >> >>
> >> >
> >>
> >>
> > 
> 
> 




More information about the sr-users mailing list