[Serusers] Hold/Unhold doesn't work with NATed clients withrtpproxy in some case...

Zeus Ng zeus.ng at isquare.com.au
Fri Mar 18 04:17:10 CET 2005


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
> 
> 1. 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.

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

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
> 
> 1. While receive the re-invite message, will ser recheck the 
> port in SDP 
> 
>    and announce rtpproxy again?

Yes, if you catch it.

> 
> 2. Is this the limitation of Ser+rtpproxy with NATed UACs?

No.

> 
> 3. Does there has any suggestion that can make this function works?
> 
>    (ser+nathelper+rtpproxy with function hold/uhhold)

See above on rtp keep-alive.





More information about the sr-users mailing list