Subject: RE: [Sipping] Loose Routing Proposal

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Sep 2001 09:05:46 -0400

But I want to get rid of the Path header, so if this doesn't
do it, we need to work harder.

I don't understand how you "learn" the route; all the cases
I know about, you know about the route, either because of
service selection or policy.  In either case, there could be
a problem of state saving (where do you keep the info),
but that is what cookies/state does.

Brian

> -----Original Message-----
> From: Miguel A. Garcia [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 8:21 AM
> To: Rosen, Brian
> Cc: 'Cullen Jennings'; [email-masked]
> Subject: Re: [Sipping] Loose Routing Proposal
> 
> 
> Hi:
> 
> Although I haven't gone through all the details in the 3GPP case, 
> my first thought is that this will solve the problem of having a
> strict route. Actually, I like Cullen's idea and the proposed 
> wording for the the bis draft.
> 
> However, this proposal does not deprecate the proposed path header,
> as proxies (or even the UA) need to learn how to preload the Route... 
> but that is another problem.
> 
> /Miguel
> 
> "Rosen, Brian" wrote:
> > 
> > I think the proposal is a good one.  I would specifically 
> like to hear
> > from the 3GPP folks if this would solve their problem.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Cullen Jennings [mailto:[email-masked]]
> > > Sent: Thursday, September 06, 2001 10:32 PM
> > > To: [email-masked]
> > > Cc: Cullen Jennings
> > > Subject: [Sipping] Loose Routing Proposal
> > >
> > >
> > >
> > > At the last IETF there was some discussion of Dave's idea of
> > > allowing both
> > > strict and loose routes to be intermixed in a single route
> > > header. I think
> > > this would address the "How to Get Outbound Services from A
> > > Non-Local Proxy"
> > > discussion and end up being more flexible and general than
> > > the path header.
> > >
> > > The basic ideas would be to add a route-type tag that can be
> > > set to loose or
> > > strict on with each name-addr in the route header. This would
> > > be taken as a
> > > hint by the proxy on how it could route the message. Strict
> > > routing would
> > > happen like normal, loose routing would have the proxy
> > > attempt to loosely
> > > route to the to the specified location in the same way it
> > > would attempt to
> > > route a message with this URI to this location. A key item on
> > > loose routing
> > > is that the sending proxy can not pop a loose route, the
> > > receiving proxy
> > > must do this when the message finally reaches the correct proxy.
> > >
> > > To make this a little more concrete, Imagine the case where a
> > > UA knows it
> > > must first go to an edge proxy called edge.visitor.com then
> > > it is going to
> > > get outbound services from a proxy called vamp1.visitor.com
> > > then another
> > > called vamp2.home.com. It has no idea of the proxies in
> > > between edge, vamp1,
> > > and vamp2. Just to pretend, lets say that vamp1 knows 
> that to get to
> > > vamp2.home.com it must send a message to the proxy
> > > nat.home.com. The initial
> > > UA could specify a route header like
> > >
> > > Route: edge.visitor.com vamp1.visitor.com;route-type=loose
> > > vamp2.home.com;route-type=loose
> > >
> > > Edge would receive this, do the normal thing and send a
> > > message to vamp1
> > > with the Route changed to
> > >
> > > Route: vamp1.visitor.com;route-type=loose
> > > vamp2.home.com;route-type=loose
> > >
> > > vamp1 would notice it was the first thing on the route header
> > > and pop this.
> > > It would than look at the next thing on the route list and
> > > see that it was a
> > > loose route to vamp2. vamp1 knows it needs to send to
> > > nat.home.com and would
> > > send a message to nat with the header of
> > >
> > > Route: vamp2.home.com;route-type=loose
> > >
> > > nat would notice this is a loose route and that it was not
> > > vamp2. It would
> > > send this message to vamp2 with a header of
> > >
> > > Route: vamp2.home.com;route-type=loose
> > >
> > > vamp2 would pop this item and the route header would be empty
> > > and normal
> > > processing would continue.
> > >
> > > Specifically I am proposing the following changes to the ABNF
> > >
> > > rr-tag = ( rr-type-tag | generic-tag ) rr-type-tag =
> > > "route-type" "=" (
> > > "loose" | "strict" | token )
> > >
> > > And adding some test to the behavior of proxies along the lines of
> > >
> > > The route-type is a hint that the proxy may honor. If a proxy
> > > receives a
> > > message and finds itself as the top most item on the route
> > > header, it must
> > > pop this item. If the top item in the route header specifies
> > > a route-type of
> > > loose, the proxy should look at the URI in the top name-addr
> > > on the route
> > > header and route the message in the same way it would route a
> > > message that
> > > had this URI and no route header. Furthermore, it should not
> > > pop the top
> > > most item off of the route list. If no route-type is
> > > specified, the default
> > > is strict.
> > >
> > > I did try and think about this idea from the point of view of
> > > backwards
> > > compatibility and I don't think there is any situation where
> > > it will make
> > > the situation worse. If a proxy that does not do loose
> > > routing attempts to
> > > route a hop that is supposed to be loose, it will try a
> > > strict route. If
> > > this works great, things carry on. If it does not work, the
> > > call will fail.
> > > The mechanism does not require that every proxy must support
> > > loose routing,
> > > only those that are going to be asked to do a loose route or
> > > receive a loose
> > > routed item need to do it.
> > >
> > > Thoughts? Thanks, Cullen
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sipping mailing list  
> http://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
> > >
> > 
> > _______________________________________________
> > Sipping mailing list  http://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
> 
> -- 
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                         Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 5140002
> 
> _______________________________________________
> Sipping mailing list  http://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
> 

_______________________________________________
Sipping mailing list  http://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: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 07 Sep 2001 16:29:23 +0300

Hi Brian:

In the current flows in 3GPP, there is a path header for REGISTER
and 200 OK. The path header is used to transport the route to 
preload in INVITES 

Preloading of the routes is done at the outbound local proxy for
outgoing calls, or at the home proxy for incoming calls.

I see that the proposal of the loose routing solves the problem
of having several proxies in the middle between a local and a
home proxy. In addition, it does not create a strict route 
between them, and this is excellent. But, like I said, this is
just one problem to solve.

The other problem that is not solved is how the local proxy might
get the knowledge of the route to apply for outbound calls in 
order to get to the home proxy. And vice versa, how does the home
proxy learn about the local proxy (this will be the route for
terminating calls, that is, home proxy, visited proxy, UA).

This is what the path header, although some of us don't like it,
it is solving.

Regards,
       
      Miguel

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 7 Sep 2001 16:49:11 +0300

Miguel A. Garcia writes:

 > order to get to the home proxy. 

i don't quit get what the problem is.  if the user wants to use its home
proxy, then the home proxy could be part of the ua's configuration and
the ua could itself add the home proxy to the route.  if the ua doesn't
care to use the proxy of the home operator, then the message would be
routed normally without an explicit route.  finally, if the use doesn't
care, but the local proxy cares, then the local proxy could find the
home proxy, e.g, from the dns using srv records.

-- juha

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 07 Sep 2001 17:42:23 +0300

Hi Juha:

This solution has been proposed to 3GPP, but didn't get quite much
acceptance, based on some concerns with the extra load in other 
network entities (e.g., HSS).

/Miguel

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 7 Sep 2001 19:30:44 +0300

> network entities (e.g., HSS).

i have hard time accepting the load argument.  all internet applications
make dns queries when started and i haven't notived any load problem
although i claim that there are many times more dns queries in the
internet than phone calls in the pstn. also, when number portability is
implemented in the pstn, each phone call starts generating dns queries
anyway.  further, i heard that even in 3gpp the query is made at the
terminating end.

so to me it looks like the real reason is something else.  using these
kind of vague load arguments it is useless to come to ietf and ask it to
standardize an g3pp specific extension.  internet applications work
using internet standardized support systems and if that is not
acceptable to 3gpp then it is better that 3gpp folks stop wasting
bandwidth on internet mailing lists.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 7 Sep 2001 12:47:32 -0500

Let's not mix the problems.

We had agreed at the ad-hoc that here were seperate problems:

1) Learning what "feature" proxies need to be traversed

and

2) Signaling that would cause the appropriate proxies to be traversed

The various loose-route proposals are solutions to problem #2. The Path
header is a proposal for solving #1 by returning a loose route vector in the
response to REGISTER.

Other possible solutions include:

a) A configuration variable in the client
b) Retrieving the vector using HTTP or LDAP, etc.
c) leaning the vector from DHCP or anothe boot-time config protocol
d) Being messaged with the vector -- NOTIFY, INFO, SMS, SMTP, etc.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 7 Sep 2001 12:51:55 -0500

3GPP wants dynamic binding between the mobile phone and its service proxies.

Their architecture calls for this binding to be defined at registration
time, hence the binding isreturned in the result of REGISTER.

I think this is a limiting or perhaps crippling requirement, but some sort
of dynamic binding approach is probably a good idea.

--
Dean

----- Original Message -----
From: "Juha Heinanen" <[email-masked]>
To: "Miguel A. Garcia" <[email-masked]>
Cc: "Rosen, Brian" <[email-masked]>; "'Cullen Jennings'"
<[email-masked]>; <[email-masked]>
Sent: Friday, September 07, 2001 8:49 AM
Subject: Re: [Sipping] Loose Routing Proposal

---

From: Jean-Francois Mule <[email-masked]>
Date: Fri, 7 Sep 2001 15:26:32 -0700

There were some emails on that topic a while ago. This concerns the
explicit indication in SDP to disable silence suppression and echo
cancellation (it is in particular applicable to fax/modem passthrough
transport).

In the process of updating the sip T.38fax I-D, i will recap the
proposed changes. Any comments?

Jean-Francois.
---------------------
+ addition of echo cancellation and silence suppression SDP media
attributes in section 6.2
  in I-D draft-mule-sip-t38callflows-01.txt

+ proposal: use the generic SDP attributes ecan and silenceSupp defined
in RFC3108 []
[] R. Kumar, M. Mostafa, “Conventions for the use of the Session
Description Protocol (SDP) for ATM Bearer Connections”, RFC3108, May
2001.

Some of the message details are changed.  Here is an example:

F15 INVITE  IFTGW UA -> PROXY
   INVITE sip:[email-masked];user=phone SIP/2.0
   Via: SIP/2.0/UDP iftgw.there.com:5060
   Route: <sip:[email-masked];maddr=ss1.wcom.com>
   From: sip:[email-masked];user=phone
   To: sip:[email-masked];user=phone
   Call-ID: [email-masked]
   CSeq: 19 INVITE
   Content-Type: application/sdp
   Content-Length: 181

   v=0
   o=faxgw1 2890844527 171091 IN IP4 iftgw.there.com
   s=Session SDP
   c=IN IP4 iftmg.there.com
   t=0 0
   m=audio 12322 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   a=ecan:fb off -
   a=silenceSupp:off 180000 - -