Subject: [Sipping] 3GPP ad-hoc meeting at IETF 53

From: "Dean Willis" <[email-masked]>
Date: Sun, 17 Mar 2002 18:28:38 -0600

We'll have an informal meeting to talk about 3GPP stuff.

Wednesday, 20Mar02, 1730 (immediately after SIPPING) to 1830, Duluth
room

The #1 agenda item appears to be discussing mechanisms for dealing with
the intermediate proxy discovery requirements raised in the 3GPP
Requirements draft. 

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 17 Mar 2002 18:51:13 -0600

Does anyone know when the SIP-Emergency (911-112) and Sip-Security Adhoc
meetings are likely going to be?

Inquiring minds....

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 18 Mar 2002 15:22:05 +0200

> the intermediate proxy discovery requirements raised in the 3GPP

after having a chance to talk with a few people at minneapolis, here is
my summary of the situation.  

originally we had two UNRELATED problems to solve:

1) how can the proxy of my home domain find a route to me for INCOMING
   requests.

2) how can i find the right "service proxy" behind the proxy of my home
   domain in case i want to route an OUTGOING request via my home
   domain.

several people seem to agree that record-register-route is a clean
solution to problem (1).

regarding problem (2) the REAL clean solution is to do nothing, because
the proxy of my home domain can always forward the initial request of a
dialog to a proper "service proxy" that can then record route itself for
further requests of the dialog.

if this solution is not (for unconvincing performance reasons)
acceptable, then next best solution to problem (2) is to introduce a
REDIRECT header that service proxy (if any) of my domain would add to
its response if it wants ALL further non-register requests from me to go
to it directly.

-- juha

---

From: "Georg Mayer" <[email-masked]>
Date: Mon, 18 Mar 2002 21:53:26 +0100

Hello Juha,

please find some comments inline.

Thanks
Georg

>
>
> > ----------
> > From: Juha Heinanen[SMTP:[email-masked]]
> > Sent: Monday, March 18, 2002 2:22:05 PM
> > To: Dean Willis
> > Cc: [email-masked]
> > Subject: [Sipping] 3GPP ad-hoc meeting at IETF 53
> > Auto forwarded by a Rule
> >
> Dean Willis writes:
>

So you say that you agree the proposals made in the path draft for the
direction Registrar to the UE - right? If we call it Record-Register-Route
or Path is a minor thing I would say.

> further requests of the dialog.

One of the possible solutions is to do nothing and to route all the initial
requests to the I-CSCF of the home network, let it query the HSS via
diameter, wait for the response which tells it the address of the S-CSCF
(which needs to be hidden in some scenarios due to requirements from US
telephony network regulation), send a redirect request to the P-CSCF and
then finally the P-CSCF (outbound proxy) sends the request to the S-CSCF
(home proxy). This costs simply too much time. We can do that under certain,
exceptional conditions, but it is simply not effective.

So using path also in the forward direction would make the dialog
establishment much more effective. So if we already use it in direction from
Home-Proxy to UE, why should it not be possible to use it in the other
direction?

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 19 Mar 2002 18:21:52 +0200

> or Path is a minor thing I would say.

i don't rememebr the details of your proposal, but as long as its
operation is the same as for normal register-route, i would accept it.
especially, exactly as in regular record-route, the ua doesn't get back
the recorded route.

 > exceptional conditions, but it is simply not effective.

i would not do it as you describe. first, as i have told before, the
service provider can locally optimize access to s-cscf information,
i.e., there is no requirement that it must use diameter.  second, the
i-cscf doesn't need to send anything to the p-cscf, but it can forward
the the request directly to s-cscf.  the response can then include the
redirect header for further requests.

-- juha