Hi everyone,
I have raised this issue in dev list but got no response, hoping some one here will be able to answer this.
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.
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 ???
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 ???
Please comment, your help will be highly appriciated. I am using CVS version of SER and RTPProxy.
Thank you Atif Rasheed
serusers is more appropriate. serdev is for development, i.e. code, not user issues.
I have raised this issue in dev list but got no response, hoping some one here will be able to answer this.
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).
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-)
On Thu, 2005-10-27 at 08:28 +0200, Greger V. Teigre wrote:
serusers is more appropriate. serdev is for development, i.e. code, not user issues.
I have raised this issue in dev list but got no response, hoping some one here will be able to answer this.
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. 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.
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-)
I have raised this issue in dev list but got no response, hoping some one here will be able to answer this.
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-)
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-)
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@burraqtel.com.pk To: "Greger V. Teigre" greger@teigre.com Cc: serusers@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-)
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@burraqtel.com.pk To: "Greger V. Teigre" greger@teigre.com Cc: serusers@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-)
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@burraqtel.com.pk To: "Greger V. Teigre" greger@teigre.com Cc: serusers@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@burraqtel.com.pk To: "Greger V. Teigre" greger@teigre.com Cc: serusers@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-)
-
Atif Rasheed -
Greger V. Teigre