[Serusers] ser-rtpproxy bridge mode and T38

[Greger V. Teigre]

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-)
>> >>
>> >>
>> >
>>
>>
>