Subject: [midcom] SIP MIDCOM flow...

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Mar 2001 17:52:23 -0800

Hi,

Can someone help me fill in the missing pieces in the following diagram? 
I'm trying to understand the flow of communication.

                       _________
                  --->|   SIP   |   
                 /    |  Proxy  |   
                |     |_________|   
               1|       |     |     
                |       |     |     
                |4      |2    |3     
   _________    |       |     |     
  | Outside |<--/      _v_____^___           ________   
  |SIP Phone|         |           |         | Inside |  
  |         |>------->| MiddleBox |>------->|  SIP   |  
  |_________|<-------<|___________|<-------<| Phone  |  
                                            |________|

Note that 1/4 is a request/response respectively.

--
Eliot Lear
[email-masked]

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: George Michaelson <[email-masked]>
Date: Fri, 30 Mar 2001 12:19:31 +1000

Hi,

                         _________
                    --->|   SIP   |   
                   /    |  Proxy  |   
                  |     |_________|   
                 1|       |     |     
                  |       |     |     
                  |4      |2    |3     
     _________    |       |     |     
    | Outside |<--/      _v_____^___           ________   
    |SIP Phone|     a   |           |    c    | Inside |  
    |         |>------->| MiddleBox |>------->|  SIP   |  
    |_________|<-------<|___________|<-------<| Phone  |  
                    b                    d    |________|

I have labelled the other paths {a,b,c,d} to make it plain they aren't
ordered. Your question lies in the space:

	"what order do {a,b,c,d} take place"

and one presumes there are sequencing differences if c predicates 3-4
being done etc etc.

ie, in a 3-way endpoint dialogue, is there end-to-end-ness for all 3 parties?

(middlebox is being directed in this exchange. circumstances where it says
 "no" seem to me to under constrains coming from other places. Or does it have
 rigid policy embedded? are there other paths left out for simplicity?)

-George

--
George Michaelson         |  DSTC Pty Ltd
Email: [email-masked]    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 29 Mar 2001 20:08:17 -0600 (CST)

> I'm trying to understand the flow of communication.

	Outside SIP Phone -- OSP
	SIP Proxy -- SP
	Middlebox -- MB
	Inside SIP Phone -- ISP

	It goes like this:

	1) INVITE from OSP to SP
	2) SP makes bind request to MB
	3) MB replies with binding of an internal address for OSP
	4) SP re-writes INVITE's SDP
	5) SP sends INVITE to ISP
	6) ISP rings and stuff until someone picks up; 200 OK -> SP
	7) SP makes bind request to MB
	8) MB replies with public address for ISP
	9) SP rewrites SDP in 200 OK
	10) SP forwards 200 OK to OSP
	11) OSP replies to 200 OK with ACK
	12) SP receives ACK and opens pinholes for media streams on
		MB (using addresses pre NAT -- hence importance of
		understanding NAT/Fwall plumbing in MB!)
	13) SP forwards ACK to ISP
	14) media flows

	Notes:

	steps 2-4 are not necessary in the easy case, where
the OSP's address is perfectly useful to the ISP as is (normal
enterprise NAT case).

	step 12 can be done almost any time you like. It makes sense to
do it on the ACK from a purist point of view. On the other hand, it may
also make sense to open pinholes early, since media can start to flow
awfully early from some phones. You can open one pinhole immediately
after step 4 (for outgoing media) and the other after step 9 (for
incoming media). Obviously you can open them any time later as well,
including as indicated.

	I think I have this right, at any rate.

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 30 Mar 2001 09:25:38 -0500

see comments below

----- Original Message -----
From: "George Michaelson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 29, 2001 9:19 PM
Subject: Re: [midcom] SIP MIDCOM flow...

>                     --->|   SIP   |<-----\
>                    /    |  Proxy  |       \
>                   |     |_________|       |
>                  1|       |     |       1a|
>                   |       |     |         |
>                   |4      |2    |3        |1b
>      _________    |       |     |         \    ________
>     | Outside |<--/      _v_____^___       \->|        |

There is a missing request/response (I've added 1a+1b above) from the SIP
Proxy to the Inside SIP Phone. Note that 1+4 and/or 1a+1b may go thru the
MiddleBox for NAT/Firewall, but that rule would have been previously
estabished.

> "what order do {a,b,c,d} take place"
These represent the RTP flow for the session and it does not really matter
whether a or d is first. None of them can begin until the NAT/forwarding
rules (forward a to c and d to b) are installed by the 2+3 transaction from
the proxy.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 30 Mar 2001 10:28:04 -0600

To simplify things a bit, in relation to SIP, I thought that I would add
this call flow to the mix. Middlebox control messages are merely examples.

SIP UA		SIP		Middle		Internal
Client 		Proxy		Box		SIP Client
|			|		    |		   |
|----INVITE------>|		    |		   |
|    		      |-----INVITE--->|		   |
|<---100Trying----|		    |		   |
|    	            |----Initiate-->|	         |
|			|<-Initiated----|		   |
|			|		    |-INVITE-->|
|			|<-----180Ringing----------|
|<--180Ringing----|		    |		   |
|			|<-------200 OK------------|
|<---200 OK ------|	  	    |		   |
|		      |----OPEN Hole->| 	   |
|			|<-OPEN Hole----|		   |
|-------ACK------>|		    |		   |
|		      |-----------ACK------------|
|			|		    |		   |
|<-------------------RTP/RTCP--------------->|
|			|		    |		   |
|-------BYE------>|		    |		   |
|			|----Terminate->|		   |
|		      |<-Terminating--|		   |
|			|		    |----BYE-->|
|			|<----------200 OK---------|
|			|----CloseHole->|		   |
|		      |<---CloseHole--|		   |
|<---200 OK-------|		    |		   |
|			|		    |          |

This flow describes a call from start to finish.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Bob Penfield
> Sent: Friday, March 30, 2001 8:26 AM
> To: [email-masked]; George Michaelson
> Cc: [email-masked]
> >  "no" seem to me to under constrains coming from other
> places. Or does it
> have

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 30 Mar 2001 12:16:50 -0500

see embedded comments below

----- Original Message -----
From: "Christopher A. Martin" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 30, 2001 11:28 AM
Subject: RE: [midcom] SIP MIDCOM flow...

> This flow describes a call from start to finish.
I believe the "Initiate" is required to obtain a NAT'd address from the
middlebox to put in the session description (SDP) of the INVITE. This is to
tell the SIP Client (called party) where to send its RTP messages (this will
be an address and port on the Middlebox). The INVITE should not stop at the
Middlebox (if the middlebox can talk SIP, there's no need for MIDCOM), but
should go from the SIP Proxy to the SIP Client after the "Initiate"
transaction with the Middlebox. Assuming the session description (SDP) is in
the 200 OK response, the "OPEN Hole" would open the hole and obtain a NAT'd
address to put in that session description to tell the SIP UA Client
(calling party) where to send its RTP (again an address and port on the
Middlebox).

If NAT is not needed, then the "Initiate" would only be required if you
wanted to "reserve" ports on the Middlebox before letting the call go thru.

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
(781) 933-6166
[email-masked]

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 30 Mar 2001 11:58:57 -0600

Bob,

Here is the corrected Call flow, other comments inline:

 SIP UA           SIP/CTRL      Middle       Internal
 Client           Proxy          Box        SIP Client
 |                 |               |          |
 |----INVITE------>|               |          |
 |                 |----Initiate-->|          |
 |                 |<-Initiated----|          |
 |			 |               |          |
 |                 |--------INVITE----------->|
 |<---100Trying----|               |          |
 |                 |               |	    |
 |                 |<-----180Ringing----------|
 |<--180Ringing----|               |          |
 |                 |<-------200 OK------------|
 |<---200 OK ------|               |          |
 |                 |----OPEN Hole->|          |
 |                 |<-OPEN Hole----|          |
 |-------ACK------>|               |          |
 |                 |-----------ACK------------|
 |                 |               |          |
 |<-------------------RTP/RTCP--------------->|
 |                 |               |          |
 |-------BYE------>|               |          |
 |                 |----Terminate->|          |
 |                 |<-Terminating--|          |
 |                 |               |----BYE-->|
 |                 |<----------200 OK---------|
 |                 |----CloseHole->|          |
 |                 |<---CloseHole--|          |
 |<---200 OK-------|               |          |
 |                 |               |          |

> Sent: Friday, March 30, 2001 11:17 AM
> To: midcom mail-list; [email-masked]
> middlebox to put in the session description (SDP) of the
> INVITE.
>This is to
> transaction with the Middlebox.

Excellent point. I have revised the call flow above accordingly.

>Assuming the session
> description (SDP) is in

Initiate would be required (I am assuming the intiate function as being an
authentication phase or such mechanism to begin the process of opening holes
in a secure manner)if for nothing more than to merely open the holes, even
in the case of no NAT, I believe.

> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Bob Penfield
> > > > ie, in a 3-way endpoint dialogue, is there
> end-to-end-ness for all 3
> > > parties?
> > > >

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 30 Mar 2001 12:04:36 -0600 (CST)

> (calling party) where to send its RTP (again an address and port on the

	A couple of remarks.

	It is definitely necessary to talk to the middlebox before
forwarding the INVITE, yes. And the reason is as indicated.

	The INVITE may be considered to hit the middlebox or to
flow through it. Since the middlebox, as indicated, more or less by
definition doesn't DO anything to the INVITE I think it's simplest
to designate it as flowing through it. I always flow signaling through
my middleboxes when I am drawing these things.

	The address/port returned by the middlebox in response
to the "Initiate" (I MUCH prefer talking about bind requests and
responses, rather than a generic "Initiate" by the way) may or may not
be an address/port on the middlebox. If the middlebox is a proper
NAT, the address is just an address drawn from the pool of addresses
available on the relevent side of the middlebox. If the middlebox
is a general purpose UDP plugboard box, then the IP address of the
middlebox might indeed be used.

	However, it doesn't matter. The point of a NAT bind request
is 'gimme an address/port I can use on THAT side to get to this
address/port on THIS side.' How the middlebox scrapes these addresses
and ports up doesn't matter.

	I enclose some material I submitted to the foglamps list
a while back which might make more sense in the current context.
In these flows, "Call Initiate" is synonymous with INVITE and
ACK is (confusingly) synonymous with 200 OK, and there is no
equivalent of the actual SIP ACK. Since the SIP ACK happens after
all the good stuff is over, this probably isn't very important,
though implementations may choose to use it to drive state machines
in interesting and useful ways. At this high level of abstraction,
I feel comfortable ignoring SIP ACKs.

-----------------------------------------------------------------

Sample Flows
============

	These are modeled on typical IP telephony call flows, and
assume a magical NAT/Firewall Middlebox device. A and B represent
two different networks, each with an Application controlling a
Middlebox, the latter located at the perimeter. In these flows,
the X's and Y's represent abstract endpoint addresses, typically
the combination of an IP address with a port, and a transport
protocol (possibly implicitly specified).

	The middlebox communication protocol should be sufficiently
rich and expressive to support these operations.

Simple Egress Firewall Control
------------------------------

	In this case, we have only our A network, with some
controlling application and a Middlebox performing normal perimeter
firewalling work. The Call Initiate winds up, through mechanisms
far outside the scope of this document, at a destination, Y, which
replies with an ACK.

	In this scenario, pinholes are opened only after the ACK
from Y is received. It may be desirable (e.g. early media) to open
the inbound pinhole earlier (see below).

           Application A     MidBox A
                 |              |
      Call Initiate             |
       from X    |              |
    ------------>|              |
                 |        Call Initiate
                 |           From X
                 |---------------------->
                 |              |
                 |              |
                 |       ACK From Y
                 |<-----------------------
                 |              |
                 | Open Pinhole |
                 |  X --> Y     |
                 |(or * --> Y ?)|
                 |------------->|
                 | ACK Pinhole  |
                 |<-------------|
                 |              |
                 | Open Pinhole |
                 |   X <-- Y    |
                 |(or X <-- * ?)|
                 |------------->|
                 | ACK Pinhole  |
                 |<-------------|
                 |              |
                 |              |
    ACK From Y   |              |
   <-------------|              |

Simple Egress Firewall Control Case II -- "Early Media"
-------------------------------------------------------

	This is the same as the previous example, except that the
inbound pinhole is opened earlier. Note that in this case there is no
ambiguity about wildcarding the first pinhole -- in general the remote
WILL NOT be known at this point, so the pinhole almost certainly must
be wildcarded.

           Application A     MidBox A
                 |              |
      Call Initiate             |
       from X    |              |
    ------------>|              |
                 |              |
                 | Open Pinhole |
                 |   X <-- *    |
                 |------------->|
                 | ACK Pinhole  |
                 |<-------------|
                 |              |
                 |        Call Initiate
                 |           From X
                 |---------------------->
                 |              |
                 |              |
                 |       ACK From Y
                 |<-----------------------
                 |     Media from Y -> X
      Media      |<-----------------------
   <-------------|
                 |              |
                 | Open Pinhole |
                 |  X --> Y     |
                 |(or * --> Y ?)|
                 |------------->|
                 | ACK Pinhole  |
                 |<-------------|
                 |              |
    ACK From Y   |              |
   <-------------|              |

	Clearly, in the case of a NACK from Y or a timeout, the pinhole needs
to be closed. This makes this scenario more of a hassle to implement, though
it will work quite a bit better in some cases.

Simple Egress NAT Control
-------------------------

	In this example, we worry only about an egress NAT device. This is
somewhat artificial, since a firewall is generally also present. However,
it is illustrative.

           Application A     MidBox A
                 |              |
      Call Initiate             |
       from X    |              |
    ------------>|              |
                 |              |
                 | NAT REQ      |
                 |  Target: X   |
                 |  Source: *   |
                 |------------->|
                 | NAT RESP     |
                 | Map: X -> X1 |
                 |<-------------|
                 |              |
                 |        Call Initiate
                 |           From X1
                 |---------------------->
                 |              |
                 |              |
                 |       ACK From Y
                 |<-----------------------
                 |              |
    ACK From Y   |              |
   <-------------|              |

	Note that the Call Initiate sent outwards to the world is
not from X but from the translated address X1.

All Singing All Dancing Firewall+NAT Across Two Networks
--------------------------------------------------------

     Application A     MidBox A            MidBox B      Application B
           |              |                   |                |
Call Initiate             |                   |                |
 from X    |              |                   |                |
  -------->| NAT REQ      |                   |                |
           |------------->|                   |                |
           | Target: X    |                   |                |
           | Source: *    |                   |                |
           |              |                   |                |
           | NAT RESP     |                   |                |
           |  Map: X->X1  |                   |                |
           |<-------------|                   |                |
           |              |                   |                |
           |             Call Initiate From X1|                |
           |-------------------------------------------------->| (locate dest
           |              |                   |                |   at Y and fwd
           |              |                   |                |   initiate)
           |              |                   |                |
           |              |                   |                |  ACK from Y
           |              |                   |                |<-----------
           |              |                   | NAT REQ        |
           |              |                   | Target: Y      |
           |              |                   | Source: *      |
           |              |                   |<---------------|
           |              |                   |                |
           |              |                   | NAT RESP       |
           |              |                   |  Map: Y->Y1    |
           |              |                   |--------------->|
           |              |                   |                |
           |              |                   | Open Pinhole   |
           |              |                   |  X1 --> Y1     |
           |              |                   |(or * --> Y1?)  |
           |              |                   |<---------------|
           |              |                   |    ACK Pinhole |
           |              |                   |--------------->|
           |              |                   |                |
           |              |                   | Open Pinhole   |
           |              |                   |  X1 <-- Y1     |
           |              |                   |(or X1 <-- * ?) |
           |              |                   |<---------------|
           |              |                   |   ACK Pinhole  |
           |              |                   |--------------->|
           |              | ACK From Y1       |                |
           |<--------------------------------------------------|
           |              |                   |                |
           | Open Pinhole |                   |                |
           |  X1 --> Y1   |                   |                |
           |(or * --> Y1?)|                   |                |
           |------------->|                   |                |
           | ACK Pinhole  |                   |                |
           |<-------------|                   |                |
           |              |                   |                |
           | Open Pinhole |                   |                |
           |  X1 <-- Y1   |                   |                |
           |(or X1 <-- *?)|                   |                |
           |------------->|                   |                |
           | ACK Pinhole  |                   |                |
           |<-------------|                   |                |
           |              |                   |                |
           |              |                   |                |
  ACK From |              |                   |                |
    Y1     |              |                   |                |
  <--------|              |                   |                |

	Note that there is an issue of whether pinholes are opened
for pre-NAT addresses, post-NAT addresses, Internal addresses or
External Addresses (there are indeed 4 cases). Indicated above, pinholes
are indicated for External addresses.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 30 Mar 2001 13:55:27 -0600

> Andrew Molitor
> Sent: Friday, March 30, 2001 12:05 PM
> To: [email-masked]
> INVITE. This is to

Then the initiate and intiated can be considered BIND REQUEST and BINDING I
can change it. The flow is actually meant to represent what a SIP call from
beginning to enbd would look like.

> and ports up doesn't matter.

Actually I consider intiate a way to perform the control that dynamically
opens pinholes, irrespective of NAT. Binding for NAT however could be
conveyed in the initiate message as part of the process (if it is developed
this way).

> I feel comfortable ignoring SIP ACKs.

I thought this would come up so I clarified in a later message (prior to any
comments...thinking on the fly) that a portion of the call flow is related
to SIP signaling and RTP flow and the rest is for middlebox control.
Middlebox control was made up of initiate, initiating, open holes, close
holes, and terminate, terminating.

The idea here is that I wanted to clarify SIP for those that wished to know
the process SIP uses.

I will read the following flows in minute, just wanted to address this.
Thanks

>  |   at Y and fwd
>  |   initiate)
>  |  ACK from Y
>  |<-----------