notes recorded by Don Stanwyck, don@stanwyck.com
Call to organized behavior - 9:00 a.m.
Jonathan Rosenberg initiates discussion on "Making SIP NAT friendly".
Problem:
· No SIP ALG in existing NATS (No commercial ALGs today)
· NATS are numerous today and won't get changed out rapidly
· IPv6 might cause NATs to get replaced or updated
· Can't force customers to upgrade NATs just because the service provider
wants to provide service over SIP (NATs are built in to many Cable modems,
DSL modems, etc.)
· So proposal is to make SIP "NAT friendly"
Draft-ietf-nat-app-guide-04.txt suggests some rules:
· Don't put IP addresses in protocols
· Clients should initiate sessions
SIP predates these guidelines - how to get it to follow them now?
· Find ways to ignore IP addresses in SIP/SDP when possible - get
information from the transport connections.
· Find ways to make peer-to-peer application look like a client server
application
· Don't rely on DNS since many clients do not have domain names.
NAT behavior for UDP is highly variable. Assumptions are that NATs let
packets out (UDP and TCP). For UDP packets can get back in only from the
original destination until the timer expires - typically many seconds to a
minute.
Reference model is 2 UAs, each with a NAT between them and the network, and
two SIP proxies between them (in the network). 4 possible configurations:
no NATs, a NAT at side A only, a NAT at side B only, NATs at both sides.
SIP over UDP is not NAT friendly - uses port from Via header. SIP over TCP
is NAT friendly - responses go back on the existing connection.
Recommendation: use TCP.
Proxy to UAS routing today is through registrations. Data is wrong - is
private address in private network. No NAT binding for it. Solution:
Use
TCP for registration, use it for incoming INVITES. UAS listens on that
connection. But contact header will not point to this connection.
Proposal: contact cookie. Special value that says I don't know my values,
please use the values from my connection and tell me what they are.
Proposes use of value like <sip user> @ invalid_hostname. This
causes the
registrar to create new value.
Fixes 3 other problems with SIP: 1) multihomed hosts, registering on
public
and private networks. Clients can't easily figure out different values, so
let server figure it out. 2) don't know my IP address. Some hosts
don't
know their own IP addresses. 3) SIP Java applets - applets can only listen
on the connection that was initiated with the server.
<comment > SIP was designed to be independent of the transport protocol.
This requires you to couple them back. TCP may go down for load balancing,
other reasons. May not know why, so everytime TCP goes down you must treat
it like registration timer expiry.
<comment - ?? > scalability question - using TCP changes scaling dynamics.
<answer> registration servers already maintain state - registration state.
For SIP to be deployed we need to find a way around NATs, and this seems the
reasonable solution.
<comment> what about periodically refreshed UDP connections instead of
TCP.
<answer> doesn't work with NAT-T.
<comment> the issue of inverting the port numbers means that you have to
have a UDP enabled NAT, but if I have a similar hack that is proposed for
TCP (I don't know my port number), it might work. <jr> maybe it
could work
with a via cookie, but doesn't solve the problem, since I can only get them
back from the same port I sent them from.
<comment> will the NAT also take care of the security issue when someone
is
trying to get into the network? <jr> yes. Need to clarify with
the
security people, but I think it does.
<comment> requires every TCP machine to have a big window. <jr>
true, which
is why it wasn't done this way to begin with. <comment> number of
connections affect scaling.
<jr> perhaps.
<comment> check with ?? - he has data on lots of implementations - they
are
all over the map. <jr> agree there is a problem, but otherwise there
is no
solution.
<comment> what about media? <jr> not there yet. Next
slides.
Hard part is RTP - current RTP is unidirectional. RTP is not NAT friendly
0
designed for multicast. Solution - make RTP look like a client server
protocol. A indicates IP/port to receive from B, B sends to A, A sends
back
to B using the source/port received in media from A. Needs only one IP
address - either party. Won't work for 2 NAT problem.
<comment> doesn't work if microphone and speaker are on different hosts.
<jr> true.
Conceptually this is symmetric RTP. Connection oriented. But who
originates? Need to define active and passive participants. See
draft-ietf-mmusic-sdp-comedia-00.txt. All we need is new keyword.
Handles two of three NAT present cases - a NAT at either end. Both sides
try, use the one that succeeds.
What about both behind NAT? Many solutions possible but require something
between them that is an RTP translator. Both users connect to the
translator.
Proxies must know if their clients are behind NATs, e.g., VIA doesn't match
source/port, and requires client to place a visten interface into VIA
header. A's proxy sends SDP with active indicated - if B is behind NAT is
a
problem. B's proxy acts as translator, modifies SDP to point to
translator.
Symmetric RTP also solves Java applet problem - SOCKS even works. Reduces
number of bindings in NATs (from 2 to 1 per connection). Works with
firewalls.
<comment> why not use RTCP to fix it? <jr> NATs don't know port
pairing
rules.
<comment> will break RTCP and the assumption of port pair. <jr>
unavoidable,
must do same thing to RTCP you do to RTP.
<comment> how does this with firewalls <jr> doesn't address
firewalls
<comment> must have holistic solution <jr> doesn't work through
firewalls
only when someone doesn't want it to work through firewalls. Draft does
mention methods of getting through some firewalls, but they are ugly.
<comment> more firewall discussion.. Proposes use of well-known ports for
UDP traffic <jr> doesn't work unless you use new demux technique on top of
UDP <comment> disagree.
<more discussion about configurations of firewall - disagreement between
commenter and jr about utility of commenter's solution.> <jr> will have
to
think more on it.
So what needs to be done? Need framework document to describe concept.
Need SIP extensions for cookie. Need SDP usage for new token, conventions
for symmetric RTP.
<comment> not a SIP problem, really a general, protocol independent
solution
for H.323, DHCP, etc. Other proposal addresses these issues. <jr>
philosophical issue - trying to solve issues for SIP. Do you want new
protocol to solve general problem, or a solution for this.
<comment> this will be required to be in every SIP client until the last
NAT
in the world disappears. <jr> true. <comment> requires us to
decide between
changing SIP as described here and abandon the way it works today, or find
other solution. <jr> this doesn't have must impact except on RTP and SDP.
This solves many other problems too. <comment> really do need to
find a
solution to this problem.
<comment> another dimension is will internal addr/port always map to same
external addr/port. I think translator causes extra overhead in the
network
<jr> not all NATs work the way commenter describes. Translator is
overhead,
unavoidable.
<comment> considered effects on RTCP? Lip sync, etc.? <jr> don't
think there
is a problem - will think about it.
<comment> is SIP designed to instantiate multicast sessions? <jr>
of course
<comment> this won't work this way - works for unicast only ,jr> true.
Want to move forward with this.
MLPP issues from James Polk
SIP Extension for Multilevel Precedence and Preemption,
draft-polk-sip-mlpp-mapping-01.txt
First proposed in Adelaide. Exclusive right now to US Gov't and NATO.
Sets
precedence and order among all voice calls to allow identification for e.g.,
preemption. Is parallel to SIP efforts, and should be in core SIP.
<comment> do we want this to a) be part of SIP or b) a separate thing or
c)
not want to do it at all? Creates a new header that has same function as
emergency header, existing is an advisory header, this makes it mandatory.
SIP bis has text to support 5 levels of "Priority" in header.
<comment>
that was put in for this - and an extension document was supposed to be
written about how to map that to MLPP.
<comment> needed to solve problem if giving resources to urgent calls.
<mp>
yes <comment> congestion is not at SIP level, instead is at socket, UDP,
or
someplace. <brian> advantage of doing it at signaling level is you know
you
were preempted. <mp> preempted user today hears tone. Also working
mlpp
over ip draft.
<comment> what about the rest of the world? <mp> nato wants it real
bad
<comment> what about the rest of the world? <comment> maybe want to
make a
generalized solution. <mp> NATO and US Gov't are rabid about this.
<comment> 1. henning change 2543 bis to define priority levels to have
additional precedence levels registred at IANA. 2. extension doc with MLPP
mode header with statement that the values are used as MLPP demands. Other
usages can define the extensions
<comment> not just NATO/US. ITU-T has at least 4 documents in this
area,
Europe uses it in private networks. ITU-T specs cover interactions with
other services, etc. <brian> can look into that as part of the
extensions.
<comment> if we go IANA who enforces prioritization. <brian> not
part of SIP
then. <comment> bad idea, need to have SIP base precedence model
that can
be overridden by alternative precedence models. <mp> MLPP uses 5 down to
1.
<comments> continued comments on variants of solutions . take it to the
list. More support for supporting the ITU-T definition of MLPP
services.
Third party call control (3PCC) - by __ Haerens and JR
3PCC for resource management - draft haerens-sip-3pcc-00.txt
Protocol flow for single media - see slides. Proposes sending return
direction SDP in a NOTIFY or INFO. Could also use re-INVITE.
Need to make
decision.
<comment> idea of 3pcc is to use sip without extensions.
More description of the slides
<comment> proposal was made in the 3GPP draft - was it considered?
<h> no.
<comment> initial invite has no sdp, sdp in first ack was used as sdp in B
direction, response was inserted in ack that went to A. <jr> assumes
sdp-held in first message <h> true. <jr> 3GPP uses different flows
and
assumptions. PRACK solution previously didn't work, but with new flows
might work.
<jr> also has problem with infinite ping-pong due to continuous
modifications. <h> not a problem.
JR proposes to work with H to synchronize proposals since both submitted ids
last day before deadline.
Enhancements proposed to COMET method. <comment> was contained in
earlier
draft - already discussing whether it is really needed. <bill marshall>
no
extensions needed to COMET as result of san diego meeting and discussions on
list. <h> not needed? <bm> not needed.
/////////
JR presentation of 3pcc updates
Problem presentation - see slides. Shows ping-pong problem.
List presented alternative flow - see slides. Problem - complex, requires
SDP manipulation and differing codec bindings
SIP Issues from that flow
INVITE on hold must not generate a hold response.
INVITE without SDP means "you tell me what SDP to use"
Still can use old flow if destination is known to be auto-answer automata.
Otherwise use new flow.
Q0S conditions difficult, not well thought out yet. No way to allow users
to hear ringing when they pick up (ideally first pick up should hear ringing
until other party picks up) - REFER to self has been proposed. Early media
issues.
<tom taylor> refer back to self to solve ringing problem has been proposed
before but has problems. <jr> true
<comment> what if you have two devices trying to do simultaneous 3pcc on
same parties - what impact does it have on held state entities. <jr>
may be
a problem if one is a B2BUA. Normally endpoint can't tell the difference
between 1st party origination and 3rd party origination.
<comment> normal behavior is that if you send SDP-hold you get SDP-hold
back. <jr> interferes with 3PCC. Need to work through services
draft.
Actually, after review of the call flows, not a problem.
<bill m.> problem seen was need to have 3rd party insert transcoder when
it
detects incompatible endpoints <jr> basic SIP problem, not 3PCC problem.
Same as INVITE without SDP to begin with. <comment> proposes
reINVITE to
solve problem.
Issues:
1) subset vs. no subset - rfc2543 inconsistent on whether SDP in response is
subset of INVITE or not. <comment> if no overlap will send 4xx
instead of
2xx.<jr> otherside doesn't know whether what I send is everything I can
do.
To determine there is an error must assume entity sends everything it can
do. Will list codes I am able to receive, even for bi-directional streams.
But maybe I can send ones I can't receive, thus causing call failure. No
way in SDP to indicate a codec can only be used unidirectionally. SDP now
can only list codecs I can use full-duplex. <discussion> problem
transcends
SIP, needs input from SDPng group. <jr> everything uses SDP
differently.
<discussion> incompatible with PacketCable in this and other ways.
Should
support most common models. Need to sync with SDPng. What is the
default
interpretation? <jr> trying to define normative text <discussion>
need to
define associations. We must first decide default - seems to now be
thatNot
sure subset is necessary?
<jr> The default is you send the codecs you can send/receive, and the
response is a subset of that. <discussion> response does not have to be a
subset of that.
<jr> problem - if A can send and receive codecs 0, 1, B can send/receive
7,
8. Want to reject call of there is no overlap. But there may be
asymmetric
codec use that would work. How to identify both bi-directional and
uni-directional codecs?
<discussion> there are two cases - symmetrical connections and
asymmetrical
connections. For symmetrical connections current methods work. Can
be
solved by adding association between media lines in an SDP. <flemming>
won'
t be acceptable since that violates base SDP spec. <discussion> need
to be
able to give B enough notion of what A can do, both uni- and
bi-directionally.
<definition> presence of multiple codecs in SDP means can do them all
simultaneously. <discussion> not everyone comfortable with this -
want way
to say can do codec 1 or 2, pick one, can't do both at same time.
<discussion> trying to figure out what exactly the problem is - proposal
to
split every stream into 2 uni-directional streams. Some feel that is not
viable because "95%" of streams are between entities that only support
bi-directional codecs.
<jr> do we have agreement that the codecs in the INVITE sdp for
send/receive
streams are codecs I agree I can both send and receive. <consensus
received>
<jr> then the response is the subset of those that party B can both send
and
receive <discussion> yes, the response should contain at least the subset
(null?), but may have others that B can send/receive. Still not determined
if the response set must intersect the initial set. <long discussion on
asymmetric use of e.g., RFC2833> <chair proposes that no SDP changes
will
be entertained here>
Moves to the list.
2) Out of time.
Summary of BOF: Record Route - proxy can record route on any method.
If UA
has no route record for a call it is set by the first received one. If it
exists it is not updated by subsequent ones.
Transfer out of consultation: <discussion> issues remain - will go to the
list.
Humbly submitted by:
Don Stanwyck, don@stanwyck.com