I suspect this is one of those questions where you know the answer ;-) Yes, you're of course right. You inject a direction=active in the failure_route, so that the GW will wait for the media before sending. However, I have had some issues with some clients that I haven't really figured completely out yet and I'm trying to be conservative. Do you have experiences where this work? If so, which GWs and clients do you have good experiences with?
When we are first at it, there is another advanced case also: Where one SIP client is non-NATed and supports connection-oriented media, you don't have to use rtp proxy. The challenge is to know that a) the client is really public and does not appear to be public due to STUN usage b) it supports connection-oriented media (Honestly, I don't really know which clients do, AFAIK only GWs have implemented this so far, but there are probably exceptions) So, if you don't use STUN at all and know your clients well, you should be able to reduce the use of rtp proxy even more... g-)
Juha Heinanen wrote:
Greger V. Teigre writes:
- PSTN-SIP when the SIP client is behind symmetric
greger,
why does pstn-sip require use of media/rtp proxy if sip client is behind symmetric nat? can't media/rtp proxy send to the same ip/port where media is coming from the client?
-- juha
Greger V. Teigre writes:
I suspect this is one of those questions where you know the answer ;-) Yes, you're of course right. You inject a direction=active in the failure_route, so that the GW will wait for the media before sending. However, I have had some issues with some clients that I haven't really figured completely out yet and I'm trying to be conservative. Do you have experiences where this work? If so, which GWs and clients do you have good experiences with?
in my configuration, i have always used pstn gw both directions without mediaproxy. proxy just adds direction=active to sdp towards gw if sip ua sis behind nat. i didn't know that there may be some issues. my gws are ciscos and i have had various sip uas such as grandstreams, cisco atas, sipuras, kphone, etc.
-- juha
Interesting, I always seem to go via the mediaproxy when going outbound to pstn or even inbound, but I dont know much about the use of direction=active, is it supported is clients these days, from what I googled it was a add-on.
Iqbal
On 4/3/2005, "Juha Heinanen" jh@tutpro.com wrote:
Greger V. Teigre writes:
I suspect this is one of those questions where you know the answer ;-) Yes, you're of course right. You inject a direction=active in the failure_route, so that the GW will wait for the media before sending. However, I have had some issues with some clients that I haven't really figured completely out yet and I'm trying to be conservative. Do you have experiences where this work? If so, which GWs and clients do you have good experiences with?
in my configuration, i have always used pstn gw both directions without mediaproxy. proxy just adds direction=active to sdp towards gw if sip ua sis behind nat. i didn't know that there may be some issues. my gws are ciscos and i have had various sip uas such as grandstreams, cisco atas, sipuras, kphone, etc.
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Iqbal writes:
Interesting, I always seem to go via the mediaproxy when going outbound to pstn or even inbound, but I dont know much about the use of direction=active, is it supported is clients these days, from what I googled it was a add-on.
it is enough that gw supports it.
-- juha
I'm a little confused. Correct me if I'm wrong. If STUN is used, the UA find out what kind of NAT it's behind by talking to the STUN server. Then the UA modify the address/port send to proxy server depend on the STUN query result. The proxy server doesn't need to know the existance of the STUN server. The STUN server's only purpose is for the UA to figure out it's "location." So, the term "go through STUN" is confusing me. The SIP packets doens't go "through" STUN, then to proxy. It should go directly to the proxy. Please clear me out, thanks.
That's correct. The UA will use STUN at boot to detect NAT behavior/type. Based on this knowledge it will calculaee it's public IP and port number and use this information in all SIP messages to the registrar/proxy. g-)
hwang@gaia.ecs.csus.edu wrote:
I'm a little confused. Correct me if I'm wrong. If STUN is used, the UA find out what kind of NAT it's behind by talking to the STUN server. Then the UA modify the address/port send to proxy server depend on the STUN query result. The proxy server doesn't need to know the existance of the STUN server. The STUN server's only purpose is for the UA to figure out it's "location." So, the term "go through STUN" is confusing me. The SIP packets doens't go "through" STUN, then to proxy. It should go directly to the proxy. Please clear me out, thanks.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
yup, the packets dont go through STUN, the client now acts, or is seen to SER as a non-natted client, but what Grag was saying is that STUN usually sends messages back, however all client sdont really use those messages correcvtly, hence do not correctly fix the client, which means even when u use stun ur client may not work properly...Greg did I semi-quote u right
Iqbal
hwang@ecs.csus.edu wrote:
I'm a little confused. Correct me if I'm wrong. If STUN is used, the UA find out what kind of NAT it's behind by talking to the STUN server. Then the UA modify the address/port send to proxy server depend on the STUN query result. The proxy server doesn't need to know the existance of the STUN server. The STUN server's only purpose is for the UA to figure out it's "location." So, the term "go through STUN" is confusing me. The SIP packets doens't go "through" STUN, then to proxy. It should go directly to the proxy. Please clear me out, thanks.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
.
Excellent! That means that the issues I have seen were probably related to some other things that I could'nt distinguish from direction=active at the time. Then it's worth picking up again. g-)
Juha Heinanen wrote:
Greger V. Teigre writes:
I suspect this is one of those questions where you know the answer ;-) Yes, you're of course right. You inject a direction=active in the failure_route, so that the GW will wait for the media before sending. However, I have had some issues with some clients that I haven't really figured completely out yet and I'm trying to be conservative. Do you have experiences where this work? If so, which GWs and clients do you have good experiences with?
in my configuration, i have always used pstn gw both directions without mediaproxy. proxy just adds direction=active to sdp towards gw if sip ua sis behind nat. i didn't know that there may be some issues. my gws are ciscos and i have had various sip uas such as grandstreams, cisco atas, sipuras, kphone, etc.
-- juha
-
Greger V. Teigre -
hwang＠ecs.csus.edu -
Iqbal -
Juha Heinanen