Hi:
I had a very basic doubt with respect to the function "hold/unhold" on ser with rtpptoxy and kphone.
Do nathelper and rtpproxy currently support hold/unhold function (with kphone 4.1.0) with nated clients ?
Or do they have other methods to acheive that function?
In my test, I put rtpproxy and ser in same pc, and two UACs are behind that pc,
When I use hold/unhold, most time it works but some times it doesn't work
I checked the ethereal log, it seems that the fail happens only when
1. hold function last less than 60 seconds.
2. once the re-invite's rtp port in SDP announced by client has been changed
to different rtp port (different from original rtp port).
So it seems rtpproxy doens't knows the ports come from both UACs have changed...
and didn't forward UACs' rtp packets.
Here is the question I have conclude from above description
1. While receive the re-invite message, will ser recheck the port in SDP
and announce rtpproxy again?
2. Is this the limitation of Ser+rtpproxy with NATed UACs?
3. Does there has any suggestion that can make this function works?
(ser+nathelper+rtpproxy with function hold/uhhold)
Thanks and best regards
Jimmy
Jimmy,
See inline.
In my test, I put rtpproxy and ser in same pc, and two UACs are behind that pc,
When I use hold/unhold, most time it works but some times it doesn't work
I checked the ethereal log, it seems that the fail happens only when
- hold function last less than 60 seconds.
Do you mean more than 60 seconds? By default, rtpproxy has a session timeout of 60s. If it detects no traffic for more than 60s, it assumes the call has finished but SER has not signal it to stop. Thus, it disconnect the call. Some UA, when on hold, does not send any RTP packets and so rtpproxy thinks they have been disconnected.
You can change the SESSION_TIMEOUT and recompile rtpproxy to support a higher value. Or, if your UA support RTP keep-alive, make it sends a packet within the 60s interval.
- once the re-invite's rtp port in SDP announced by client
has been changed
to different rtp port (different from original rtp port).
Most likely you have not catch re-INVITE and signal rtpproxy about that. One area to look at is within your loose route routine.
So it seems rtpproxy doens't knows the ports come from both UACs have changed...
and didn't forward UACs' rtp packets.
Here is the question I have conclude from above description
- While receive the re-invite message, will ser recheck the
port in SDP
and announce rtpproxy again?
Yes, if you catch it.
- Is this the limitation of Ser+rtpproxy with NATed UACs?
No.
Does there has any suggestion that can make this function works?
(ser+nathelper+rtpproxy with function hold/uhhold)
See above on rtp keep-alive.
Hi Zeus: No, although the rtpproxy default timeout value is 60, In my test, if hold last more than 60 secs, the rtp packet is ok after unhold Seems ser will announce rtpproxy to rebuild another session, Only when (1)holding time less than 60 sec, and (2)kphone change the rtp port, then the rtp session will failed, If holding less than 60 sec, but kphone doesn't change the port, The rtp packet will transfer correctly.
So, now I have two ways to achieve the goal (1). Use rtp-keep -alive in client side (2). In ser routing script, catch the re-invite and signal rtpproxy the changes? Is there any reference or example about (2)?
Thanks and regards Jimmy
-----Original Message----- From: Zeus Ng [mailto:zeus.ng@isquare.com.au] Sent: Friday, March 18, 2005 11:17 AM To: 'jimmy' Cc: 'Iptel-Seruser' Subject: RE: [Serusers] Hold/Unhold doesn't work with NATed clients withrtpproxy in some case...
Jimmy,
See inline.
In my test, I put rtpproxy and ser in same pc, and two UACs are behind that pc,
When I use hold/unhold, most time it works but some times it doesn't work
I checked the ethereal log, it seems that the fail happens only when
- hold function last less than 60 seconds.
Do you mean more than 60 seconds? By default, rtpproxy has a session timeout of 60s. If it detects no traffic for more than 60s, it assumes the call has finished but SER has not signal it to stop. Thus, it disconnect the call. Some UA, when on hold, does not send any RTP packets and so rtpproxy thinks they have been disconnected.
You can change the SESSION_TIMEOUT and recompile rtpproxy to support a higher value. Or, if your UA support RTP keep-alive, make it sends a packet within the 60s interval.
- once the re-invite's rtp port in SDP announced by client
has been changed
to different rtp port (different from original rtp port).
Most likely you have not catch re-INVITE and signal rtpproxy about that. One area to look at is within your loose route routine.
So it seems rtpproxy doens't knows the ports come from both UACs have changed...
and didn't forward UACs' rtp packets.
Here is the question I have conclude from above description
- While receive the re-invite message, will ser recheck the
port in SDP
and announce rtpproxy again?
Yes, if you catch it.
- Is this the limitation of Ser+rtpproxy with NATed UACs?
No.
Does there has any suggestion that can make this function works?
(ser+nathelper+rtpproxy with function hold/uhhold)
See above on rtp keep-alive.
Hi Zeus: Thanks for your help
Another question about the solution... When I check the changes of rtp port in SDP while UAC sending re-invite to unhold the session, If the rtp port UAC wants in SDP has changed, does I need to first unforce_rtpproxy to signal rtpproxy destroy the previous rtp session (used before unhold), Then force_rtpproxy to signal rtpproxy to build new rtp session for the re-invite (used after unhold)? Or just force_rtpproxy without first unforce_rtpproxy ? Regards, Jimmy
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Zeus Ng Sent: Friday, March 18, 2005 11:17 AM To: 'jimmy' Cc: 'Iptel-Seruser' Subject: RE: [Serusers] Hold/Unhold doesn't work with NATed clientswithrtpproxy in some case...
Jimmy,
See inline.
In my test, I put rtpproxy and ser in same pc, and two UACs are behind that pc,
When I use hold/unhold, most time it works but some times it doesn't work
I checked the ethereal log, it seems that the fail happens only when
- hold function last less than 60 seconds.
Do you mean more than 60 seconds? By default, rtpproxy has a session timeout of 60s. If it detects no traffic for more than 60s, it assumes the call has finished but SER has not signal it to stop. Thus, it disconnect the call. Some UA, when on hold, does not send any RTP packets and so rtpproxy thinks they have been disconnected.
You can change the SESSION_TIMEOUT and recompile rtpproxy to support a higher value. Or, if your UA support RTP keep-alive, make it sends a packet within the 60s interval.
- once the re-invite's rtp port in SDP announced by client
has been changed
to different rtp port (different from original rtp port).
Most likely you have not catch re-INVITE and signal rtpproxy about that. One area to look at is within your loose route routine.
So it seems rtpproxy doens't knows the ports come from both UACs have changed...
and didn't forward UACs' rtp packets.
Here is the question I have conclude from above description
- While receive the re-invite message, will ser recheck the
port in SDP
and announce rtpproxy again?
Yes, if you catch it.
- Is this the limitation of Ser+rtpproxy with NATed UACs?
No.
Does there has any suggestion that can make this function works?
(ser+nathelper+rtpproxy with function hold/uhhold)
See above on rtp keep-alive.
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
jimmy -
Zeus Ng