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

From: "Anderson, Todd A" <[email-masked]>
Date: Fri, 30 Mar 2001 10:26:25 -0800

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

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

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 30 Mar 2001 13:58:11 -0500

----- Original Message -----
From: "Anderson, Todd A" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 30, 2001 1:26 PM
Subject: RE: [midcom] SIP MIDCOM flow...

> updated to reflect this sequence.

Correct.
>  |                 |<----------200 OK---------|
Are these really 2 different functions? or can they be done as 1? If it is
just a NAT, you don't need to close the hole.

Also, there is no need for the proxy to hold on to the BYE while
communicating with the middlebox. Doing this may cause the calling side to
re-transmit the BYE.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 30 Mar 2001 16:23:17 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Anderson, Todd A
> Sent: Friday, March 30, 2001 12:26 PM
> To: [email-masked]'

I am actually performing two functions above. I am considering intiate and
terminate to be the process for opening and closing communications between
controller and middlebox (with authentication, and perhaps
intiating/terminating an encrypted path), and open/close hole as the action
request and verification.

I probably need to tie midcom terminology into this call flow.

Now that I have clarified this for myself more comments below...

>  |                 |<----------200 OK---------|

Using my clarification above, your correction would be exactly how it should
look.

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 30 Mar 2001 16:53:10 -0600 (CST)

> I probably need to tie midcom terminology into this call flow.

	Goodness! With this definition of Initiate and Terminate, I
cannot imagine why they're tied in to a call flow. Surely these are
separate operations which happen entirely outside the call processing
path? I suppose you COULD re-authenticate for every call, but why on
earth would you want to?

	I think the authentication transaction, and the corresponding
"log out" transaction should be completely decoupled from pinholes and
stuff. Obviously a Client (or Controller) may elect to do them as
indicated, but anything wishing to Go Fast will surely tend to
authenticate fairly infrequently.

	I realize that these call flows are just intended as sort of
typical applications, but I think it's unrealistic to indicate
the Initiate and Terminate transactions this closely. If I were
drawing the flows, I'd have an Initiate transaction first, and then
an indication of 'some amount of time passes' and then the call setup
and the call teardown and then another 'some amount of time passes'
followed by the Terminate.

	Somewhat related, are there standard words for this? Surely the
IPSEC people invented some words for this sort of thing? In the
absence of other words, I would suggest Authenticate and Logout, or
Connect and Disconnect, or something. These words are probably as
meaningless to others as Initiate and Terminate are to me, though.