Subject: RE: [midcom] SIP MIDCOM flow...

From: Tim Rang <[email-masked]>
Date: Thu, 29 Mar 2001 21:28:24 -0500

I guess I read the question somewhat differently...

> -----Original Message-----
> From: George Michaelson [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 9:20 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [midcom] SIP MIDCOM flow... 
> 
> 
> 
>   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|     a   |           |    c    | Inside |  
>     |         |>------->| MiddleBox |>------->|  SIP   |  
>     |_________|<-------<|___________|<-------<| Phone  |  
>                     b                    d    |________|
>   
>   Note that 1/4 is a request/response respectively.
>   
> 
> 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"

What your diagram is missing is the SIP signaling that occurs between SIP
Proxy and Inside SIP Phone.  Segments a and c cannot occur until signaling
is exchanged between those 2 specifying the desired media for that phone.
So, while your timing for when you set policy at the middlebox is a Proxy
implementation question, a and c cannot occur until something along these
lines occurs-
5. Proxy --> Inside SIP Phone
6. Inside SIP Phone --> PRoxy
7. Proxy --> Middlebox
8. Middlebox-->Proxy

... at which time, what you specify as 4 can occur.

Tim Rang

> 
> 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
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom
> 

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

---

From: Tim Rang <[email-masked]>
Date: Fri, 30 Mar 2001 13:36:39 -0500

> From: Anderson, Todd A [mailto:[email-masked]]
> Sent: Friday, March 30, 2001 1:26 PM
> To: [email-masked]'
> Subject: RE: [midcom] SIP MIDCOM flow...
> 
> 
> In the hangup sequence, am I wrong in my understanding that 
> the SIP proxy
> should send the bye to the internal client and not the 
> middlebox?  Diagram
> updated to reflect this sequence.
> 
>  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-------|               |          |
>  |                 |               |          |
> 
> Just for my own understanding, why are terminate and 
> closehole in the order
> presented here?  My intuition would say to unroll the stack 
> as it were and
> closehole first followed by terminate.  Either of these seems 
> to have the
> problem though that it causes the bye and 200 OK between the 
> proxy and the
> internal client to fail, either because there is no NAT binding or no
> pinhole to go through.  Why wouldn't the following work?  
> Would appreciate
> someone to educate me on this issue.
> 
>  |                 |               |          |
>  |-------BYE------>|               |          |
>  |                 |-----------BYE----------->|
>  |                 |<----------200 OK---------|
>  |                 |               |          |
>  |                 |----CloseHole->|          |
>  |                 |<---CloseHole--|          |
>  |                 |               |          |
>  |                 |----Terminate->|          |
>  |                 |<-Terminating--|          |
>  |<---200 OK-------|               |          |
>  |                 |               |          |
> 
> Todd
> 
> 
> 

Both MAY be acceptable.  I don't think that the way someone draws the
picture (or builds their proxy for that matter) is so important to us as
making sure all of the potentially required operations are represented.  I
think either the original drawing or the latest will work depending upon
what you are looking for.  The only thing in the call flow that is
absolutely prescribed for SIP to work is that a translation be obtained
before the INVITE and SDP containing response are forwarded for purposes
already stated.  Whether someone does a hole open on the 200 or the ACK and
whether a hole is closed after the BYE or the 200 to the BYE is a matter of
what you are trying to accomplish.

Tim Rang