[Serusers] ser-rtpproxy bridge mode and T38

[Greger V. Teigre]

If you record route, the re-INVITE will have a Route header and thus be
picked up by loose routing.
I'm glad you solved the problem.
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: Friday, October 28, 2005 07:28 PM
Subject: Re: [Serusers] ser-rtpproxy bridge mode and T38


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