Subject: [SIP] A question about Stateful Proxies, Session Timers, and the Contact field

From: Kim Liu <[email-masked]>
Date: Fri, 14 Jul 2000 10:08:46 -0400

Hello --

I have  a question about the following scenario.

      Proxy1<---->Proxy2
       /             \
    Client1        Client2

Proxy1 and Proxy2 are stateful servers.

Let me see if I understand what is happening correctly:

C1 sends an INVITE to C2 with a Contact field indicating the location of

C1.  The INVITE travels C1->P1->P2->C2.  C2 sends a 200 OK response with

a Contact field containing the location of C2.  The response travels
C2->P2->P1->C1.

C1 sends an ACK based on the Contact field it received in the 200 OK
response, and the ACK travels C1->C2, bypassing the stateful proxies.
Later on, when either C1 or C2 sends a BYE, they communicate directly
with each other based on the contact field, also bypassing the
stateful proxies.  If this is correct, how do the stateful proxies
ever know that the call has terminated?  (i.e. to know when to stop
billing, perhaps.)

On the face of it, the Session Timer
(draft-ietf-sip-session-timer-01.txt)
idea sounds like a possibility, but I am not sure how the Session Timer
should interact with the Contact field.  That is, if C1 starts a call
with a session timer and initially routes the message through Proxy1,
then in the 200 response receives a Contact field with the direct
location of C2, should it send the session refresh straight to C2?
If so, Proxy1 and Proxy2 will never see the refreshes and are justified
in sending a BYE request to the clients, if I understand the draft
properly.  This seems undesirable.

On the other hand, if the session refreshes are to travel the same path
as a fresh INVITE message, ignoring any information received in the
Contact field in the response, doesn't this run into some issues with
forking proxies and changing REGISTER requests?  (i.e. Client2 sends a
REGISTER to P2 that C2 is going to be in a conference room for the next
60 minutes.  55 minutes later, C2 receives a call with a session timer
with an interval of one refresh every three minutes.  3 minutes into the

call, the first refresh arrives.  5 minutes into the call, the
REGISTERed
location of C2 in the conference room expires.  6 minutes into the call
the next session refresh is sent, and never reaches C2 because the
INVITE routing has changed, so C2 terminates the call. (?))

Also, if a new REGISTER message came in with a higher preference during
a call, and the session refresh INVITE was sent to the new destination
(or forked), would the new client be able to recognize the refresh as
a refresh and not as a new call?  Perhaps instead of sending an INVITE
as
the session refresh, a client could send an ACK?  The INVITE request by
nature appears more oriented towards causing a change of state, whereas
the ACK request seems to fit the role of (periodic) acknowledgement
somewhat better.

Any pointers to where this is clarified would be appreciated.  The
session
timer draft (draft-ietf-sip-session-timer-01.txt) does not appear to
mention the Contact header at all.

Thank you,
Kim Liu

Software Engineer
[email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 14 Jul 2000 15:51:10 +0100

> C1 sends an INVITE to C2 with a Contact field indicating the location
> of C1.  The INVITE travels C1->P1->P2->C2.  C2 sends a 200 OK
> response with a Contact field containing the location of C2.  The
> response travels C2->P2->P1->C1.

Sounds good to me.

> stateful proxies.

Correct, with one caveat: Record-Route.  (There are other instances
such as organizations mandating the use of an outbound proxy, but
typically you've just moved the problem one hop along.)

> If this is correct, how do the stateful proxies

Call-Stateful proxies typically "enforce" their knowledge of
callstate by means of the Record-Route header.  I'll refrain
from writing a boring essay on the subject -- it's well covered
in the RFC -- save to say that Record-Routes are like Vias,
except they are decremental rather than incremental.

Note that "stateful" in the SIP sense doesn't require the proxies
to be in the path of any subsequent requests for a call leg.  All
it means is that a server remembers a given request for some period
of time (nominally based around the SIP retransmission timers).

> idea sounds like a possibility, but I am not sure how the Session
> Timer should interact with the Contact field.

Session-Timer doesn't have any impact on basic protocol operation;
that is, clients send re-INVITEs to the same place as they always
would.

> That is, if C1 starts a call

This is correct (although proxies are not allowed to initiate BYE
requests).  If the proxies need to be in the signalling part, they
should add Record-Route headers.

> Perhaps instead of sending an INVITE
> as the session refresh, a client could send an ACK?  The INVITE
> request by nature appears more oriented towards causing a change
> of state, whereas the ACK request seems to fit the role of
> (periodic) acknowledgement somewhat better.

No.  There is no need to use ACK since INVITE works perfectly
well.  Furthermore, ACK would be no better because it is subject
to the same routing decisions as INVITE (when there is no
obviously-related INVITE), and ACKs are unacknowledged, which
would be unhelpful for the UAC. &:)

HTH,

 - Jo.

---

From: Kim Liu <[email-masked]>
Date: Fri, 14 Jul 2000 11:25:43 -0400

> typically you've just moved the problem one hop along.)

Record-Route does not seem to be listed in Appendix A "Minimal
Implementation" for basic clients.  Should Record-Route be required to
be understood by a minumal basic client implementation (as opposed to
the firewall friendly one)?  If not, then the use of Record-Route is not
going to be an assured solution.  Otherwise, sure.

Out of curiosity, are there going to be options to allow for the
encryption of the Record-Route path the same where you can Hide
Via headers, so that if you are trying to hide the route taken by a
message across your internal network of stateful proxies you can?

> that is, clients send re-INVITEs to the same place as they always

I assume that the re-INVITEs would then follow the route from the
Record-Route header (if available) to route the re-INVITEs to avoid
issues such as forking proxies, changing registrations, etc?  Okay,
that works for me, as long as all clients understand Record-Route.

Thanks for the clarifications,
Kim

Kim Liu
Software Engineer
[email-masked]

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 14 Jul 2000 16:51:06 +0100

> the firewall friendly one)?  If not, then the use of Record-Route is
> not going to be an assured solution.  Otherwise, sure.

This is a good point; I even note that obeying Route: is only
a SHOULD.

It's quite difficult to enforce that a UA/proxy/whatever obeys
Record-Route/Route without resorting to some sort of notion of
servers only accepting requests for trusted hosts/domains, or
something.  I guess from an organizational point-of-view, you can
put firewalls at all the salient points, then your ALG-cognizant
proxies mandate themselves by virtue of the fact that only they
can open up the holes.

One solution is to sit lightweight proxies (which are known to
obey Route headers) in front of UAs, but I guess what it comes down
to is that you ensure you buy from a vendor that does the Right
Thing.

> message across your internal network of stateful proxies you can?

I'm not really in a position to comment on this &:), although do
I dimly remember some discussion from the 4th Bake-Off?  (I'm
actually struggling to see how this could possibly work...although
perhaps if UAC and UAS were presented with headers encrypted in
the appropriate "direction"...Hmmm....)

> that works for me, as long as all clients understand Record-Route.

Indeed.

 - Jo.

---

From: Kim Liu <[email-masked]>
Date: Fri, 14 Jul 2000 12:03:17 -0400

> This is a good point; I even note that obeying Route: is only

Hmm.  Perhaps that as part of the session timer specfication it should be
required that any client supporting the session timer must also support
the route/record-route headers?

Cheers,
Kim

Kim Liu
Software Engineer

---

From: David Daiker <[email-masked]>
Date: Fri, 14 Jul 2000 16:33:36 -0400 (EDT)

What should be the interaction of record-route and hide:hop/route ?

Should a proxy remove the 'hide:' header it it's going to turn
on record-route ?

or should proxies encrypt the previous hop route if they're handling
requests and responses with privacy and a route header ?

What were some of the comments at the bake-off ?

thanks,
david

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 16 Jul 2000 10:30:56 -0400

> the route/record-route headers?

I think whats needed is qualification in the draft about what you will
get and
be able to do with a minimal implementation. Client to client calls is
one of them, but
calling through proxies is likely to cause problems if you don't support
record-route. 
For all intensive purposes its a MUST if you actually want someone to
buy your product...

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 16 Jul 2000 10:33:15 -0400

> the appropriate "direction"...Hmmm....)

It just doesn't work. Unlike Via, where the encryption happens in one
direction (downstream), and decryption in the other (upstream),
Record-Route
results in the construction of Route headers that are used for
subsequent
requests from called UA to calling UA, *AND* calling UA to called UA.
This means
you can't encrypt either the Record-Route before or after your own...

-Jonathan R.

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 17 Jul 2000 11:39:20 +0100

> What should be the interaction of record-route and hide:hop/route ?

There is no interaction, per se -- they are completely orthogonal.

> requests and responses with privacy and a route header ?

Proxies should obey the Hide headers as they would do if there
were no [Record-]Route headers present, and vice-versa.

I would note, however, that using Hide together with Record-Route
is pretty-much oxymoronic. &:)

> What were some of the comments at the bake-off ?

As Johnathan pointed out, doing something akin to Hide, except
with [Record-]Route is impossible.  I must have been hallicunating,
or something, and imagined it all
(does the phrase "Cycling Bowler Caps" mean anything to anybody?)

Cheers,

 - Jo.

---

From: David Daiker <[email-masked]>
Date: Mon, 17 Jul 2000 09:54:14 -0400 (EDT)

Jonathan, actually I think it *could* be done. Just like 'via' encryption, btw,
with the exception that on responses the downstream route is encrypted,
not popped. That way the caller sees only the 1st (record-route) downstream
proxy in the clear, and the callee sees only the final one.

david

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jul 2000 10:48:29 -0400

> proxy in the clear, and the callee sees only the final one.

The record-route in the responses will have already been encrypted,
since the response reflects the request, which was encrypted in the
forward direction....

-Jonathan R.