Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 2 Nov 2005 13:32:02 -0500

See Jonathans references to inbound and outbound.

Typically, one side of the NAT is considered private IPv4 space (inside)
v. public (outside).
Outbound is from private to public and inbound vice-versa.

My main point was that the example you cited may have been working
because of the type of NAT and the direction that the periodic messages
were flowing.  Some NATs only refresh the mapping when the messages are
going outbound.

An SP NAT would have the network messages going "outbound" toward the
client.
A customer NAT would have the network messages going "inbound" to the
client.

That latter NAT might not keep the mapping alive if only network traffic
were received and blackholed by the client.  The client NAT might at
some point close down the mapping.

A specific example doesn't prove the general case.

Mike

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Wednesday, November 02, 2005 12:43 AM
> To: Michael Hammer (mhammer)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal
> 
> Michael Hammer \(mhammer\) writes:
> 
>  > Is there a dependency here on the type of NAT and which 
> side is inside  > v. outside? Are all NATs in question under 
> SP control?
> 
> the NATs are what user buy, so service provide has little 
> control on them.  of course, if service provider knows that 
> certain NATs are broken, it may warn about them.  most of the 
> NATs that my user buy seem to be symmetric, so we gave up on 
> STUN about a year ago.
> 
> i don't know what you mean by inside and outside.  in our 
> case, sip and media proxies have global addresses.
> 
> i still haven't got any answer why something would need to be 
> standardized for this kind of stupid UA/stupid NAT scenario, 
> intelligent sip proxy/media proxy, since it seems to work 
> fine within the limits of already existing standards.
> 
> -- juha
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 3 Nov 2005 08:23:42 +0200

> A specific example doesn't prove the general case.

no, but if you have two choices: wait for sip UAs to become NAT aware
and be able to send keepalives properly or have them work now using
proxy generated keepalives, which works in very many (but not all)
cases, which one would you choose?

as i said in another message,  this is not just A specific example.  it
seems that proxy generated keepalives work fine for MOST nats on the
market (at least those in common use in finland).

-- juha