Subject: Re: [SIP] Identification problem

From: Bertil Engelholm <[email-masked]>
Date: Mon, 06 Nov 2000 14:47:26 +0100

See comments below.

/Bertil

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Bertil Engelholm [mailto:[email-masked]]
> > Sent: Friday, November 03, 2000 10:54 AM
> > To: [email-masked]
> > Subject: [SIP] Identification problem
> >
> >
> > Hi,
> >
> > Sofar noone have responded to the problem below so this
> > third time I send it I try a new subject. I was hoping
> > that some SIP responsible people would come up with a
> > solution to the problem or atleast say if it is regarded
> > as a problem or not.
> 
> Well, back in the good old days, the SIP list generated just a few messages
> a day. I used to be able to respond almost immediately to every question.
> Now, as we approach the average of 30 messages per day, it is impossible for
> me, and many of the other SIP experts, to respond to every question on the
> list.
> 
> Anyway, to answer your question, I can think of a few additional
> possibiltiies:
> 
> 1. P1 use a different IP address (i.e., different maddr) as the request
> cycles through each time. This requires detection of the spiral and
> selection of a different address each time. This can be done statelessly,
> since the previous maddr inserted will appear somewhere in the Record-Route
> list when the request arrives again. This has the drawback of requiring a
> server to be configured with some number of IP addresses.

This is a little bit to much of a hack solution for my taste.
How many IP-addresses do you need ? How many times can you
spirale through a proxy ?

> 
> 2. The difference between the requests coming to P1 the first time and
> second time is not just the top Via, but also the contents of the Route
> header. What you can do is this: when the response to the initial INVITE
> comes, the response carries the complete RR trace. You should be able to
> infer from the request and the response what the Route header set will look
> like by the time the messages reach P1, and this will be different for both
> times the request arrives.

This might be a possibly solution but only if it's totally
forbidden for a proxy to jump off a route chain after some
requests. Since you should add new record-route for every
new request a proxy can technically remove himself from the
list in the middle of a call or is this forbidden ??

> 
> 3. As Sean has pointed out, the State header is another possibility. There
> is the unfortunate problem that this won't work if both UAs don't support
> the State header, so you pretty much need a non-State based solution anyway.

Isn't the State header a separate draft ? Can I require that all
devices have implemented this draft. I would prefer a solution
that is included in RFC2543.

> 
> Note that according to the spec now, the UAS does copy ONLY the maddr and
> port from the RR header; everything else comes from the Contact/From.
> 
> > The first solution is to remove the text where it says
> > that a UA should fill all Routes with values from
> > CONTACT or FROM. Instead the original addresses should
> > be kept. Personally I find it strange when you combine
> > addresses (from CONTACT/FROM) with a port number from
> > RECORD-ROUTE. This means that the total address now is
> > completely useless. It looks to me that you try to
> > avoid syntax changes in the protocol at all costs. I
> > don't understand why a change in semantics is regarded
> > as more backwards compatible than a change in the syntax ?
> 
> Because internal semantic processing does not require communications between
> devices. Thus, you can maintain interoperability. Its the "black box"
> paradigm; you have a hard time changing the interface between components in
> a system, but you can easily change the internal implementation and
> processing logic.
> 
> That aside, the motivation for doing this oddball combination was to try and
> preserve a "fundamental invariant" of SIP, which was that the request URI
> should always refer to an entity that the request is actually addressed to.
> If the UAS simply uses the Record-Routes as is for the Route header, this
> won't be true. The result is a certain amount of brittleness.
> 
> Now, I'm going to open a huge can of worms here.
> 
> First, it seems I am in the minority of folks who think this approach
> (mixing the RR and From/Contact) is sensible. I'm willing to entertain the
> notion that preservation of a protocol invariant is less important than real
> protocol operational problems. Since the maintenance of this invariant is
> causing problems with spirals, perhaps it is not worth the pain, and we
> should return to the original notion of just using the list in the order you
> got it.
> 
> Now, to make things more complex, we have a slight problem that
> record-routing has troubles when the request URI in the incoming request is
> not a SIP URL. Thats because, as you may recall, the RR process in a proxy
> is to COPY the request URI into the RR, and then modify the maddr and port.
> Now, maddr and port are SIP URL parameters. There are no such things for the
> tel URL, for example. Thus, record routing a request with a tel URL is a bit
> problematic. You basically need to convert it to a SIP URL first, or do
> something else. Converting everything to SIP URLs may not always be possible
> down the road. One can make the argument, and I would agree with it, that
> the IP address and port of the proxy are not URI parameters, but
> record-route header parameters. We did the hack of putting them in the URI
> maddr and port since this is backwards compatible.
> 
> So, perhaps we should consider defining address and port record-route
> parameters. These would only be set when the request URI contained a non-SIP
> URL. Proxies would use these parameters if present for routing instead of
> the maddr and port in the URL.
> 
> COmments? (I'm sure there are).
> 
> -Jonathan R.
> 
> >
> > I would have prefered to add a port number in the
> > maddr parameter because that's where I beleave it belongs.
> >
> > The second solution is to make it possible for a server
> > to add it's own parameter in RECORD-ROUTE and then get
> > it back in the REQUEST. Today a UAS only supposed to
> > copy maddr and port value from RECORD-ROUTE to ROUTE.
> > If all parameters was copied instead it would be possible
> > for a server to add anything it likes in RECORD-ROUTE
> > and get it back again. I beleave this kind of solution
> > have been discussed for states ?
> >
> > /Bertil
> >
> > Bertil Engelholm wrote:
> > >
> > > Hi again,
> > >
> > > I'm sorry to bring this up again but I just can't get things
> > > to work in the correct way. I have read through the old threads
> > > regarding this matter and still don't understand how it is
> > > suppose to work.
> > >
> > > It's this example again :
> > >
> > >   ---------                  --------                  --------
> > >   | a@c1  | -- INV u1@p1 --> | (s1) | -- INV u2@p2 --> |      |
> > >   ---------  (contact a@c1)  |      |                  |      |
> > >                              |  p1  |                  |  p2  |
> > >   ---------                  |      |                  |      |
> > >   | b@c2  | <- INV b@c2 ---- | (s2) | <- INV u3@p1 --- |      |
> > >   ---------                  --------                  --------
> > >
> > > If P1 is stateful it might allocate one "call" state machine for
> > > each path the "call" takes in P1 (s1 and s2 in the picture).
> > > These two state machines are identified by the REQUEST-URI
> > > that came in the two INVITEs since that's the only thing that
> > > differs the two from each other. (topmost VIA also differs,
> > > more about that later)
> > >
> > > P1 will now include the REQUEST-URI in the branch value it
> > > generates so that the responses can be directed to the right
> > > state machine when they arrive. And when the ACK is sent the
> > > original REQUEST-URI from ROUTE is used. So no problems here.
> > >
> > > The problem I have is when b@C2 sends a new request (eg. BYE).
> > > According to the specification b should/must/may (or whatever)
> > > overwrite the REQUEST-URI in the ROUTE headers using the
> > > REQUEST-URI from CONTACT or FROM.
> > >
> > > So how should P1 now be able to differ the two (BYE) requests
> > > from each other ? The Original REQUEST-URI was the only thing
> > > that P1 had to identify the two state machines.
> > >
> > > When reading the old threads regarding this matter I saw
> > > something about using topmost VIA in some way, but how ?
> > >
> > > By using the topmost VIA you can see that they are two different
> > > requests but how do you identify which state machine should receive
> > > the first request. (Someone might argue that it doesn't
> > matter but if
> > > P1 controls a firewall it DO matter. Maybe not for BYE but for a
> > > RE-INVITE it matters).
> > >
> > > --
> > > Bertil Engelholm
> > > AXE Research and Development        voice : +46 8 727 3499
> > > SIP Security                        Fax   : +46 8 647 8276
> > > S-126 25 Stockholm Sweden           E-mail:
> > > [email-masked]
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> >
> > --
> > Bertil Engelholm
> > AXE Research and Development        voice : +46 8 727 3499
> > SIP Security                        Fax   : +46 8 647 8276
> > S-126 25 Stockholm Sweden           E-mail:
> > [email-masked]
> >
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> >
> 
> ---
> 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: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Bertil Engelholm
AXE Research and Development        voice : +46 8 727 3499
SIP Security                        Fax   : +46 8 647 8276
S-126 25 Stockholm Sweden           E-mail:
[email-masked]

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 7 Nov 2000 20:02:48 -0800

> 
> Another potential solution is to slightly change the way 
> Route headers are
> constructed. Right now, the spec says:
> 
> ----
> If a UA finds a Record-Route header in a request received as a UAS, it
> copies the Record-Route
> maddr parameters and any port value, maintaining their 
> ordering, to the
> Route header field of future
> requests issued as a UAC. Since the URIs contained in the Record-Route
> header fields are not useful for
> the reverse request path, the UA fills all other components 
> of the Route
> name-addr value with the name-addr
> value found in the Contact or the From header field. The 
> latter is used only
> if there is no Contact
> header field.
> ----
> 
> as I pointed out, this causes everything from the 
> Contact/From to be copied
> into Route, EXCEPT port and maddr. How about if we say that the Route
> contains the user:password@host portion of the Contact/From, 
> and everything
> else is copied from the Record-Route? THis would include unknown URL
> parameters.
> 
> The advantage here is that one could insert URL parameters into the
> record-route, and get them back in the request URI. Not the 
> prettiest way to
> go. 

I was thinking along the same lines - I think this would solve a couple of
problems. 

Firstly, I can't see it causing any backward-compatibility problems as any
"other parameters" in the Request-URI (ie implementation specific
Record-Route paramters) are simply going to be ignored by other proxies that
may see the Request-URI. That is, no changes required anywhere except in the
way the proxy builds its _own_ Record-Route entry - perfect. 

Secondly, this solves the stored Record-Route state problem (ie, the proxy
never sees the information stored in the Route entry because it is
overwritten ). This means that Record-Route-ing can be done statelessly -
probably important in OPTIONS and other non-INVITE Record-Routing that don't
have any BYE/Expire sequence to clean up the Route information.

We should however define a standard Record-Route "branch"-like options names
for implementation specific information - so we don't get clashes on
Request-URI option names. However, a proxy which understands the new Route
options should _only_ act upon the the route-state header _if_ it can
identify that the header was created by itself. 

In furtherance of the above and in solving the maddr:port problem for
non-sip URL's, then a proxy SHOULD also add a record-route address headers
(and MUST do so if the proxy adds a rroute state header ). How about .......

Record-Route: [Request-URI];rr-host=host:port;rr-state=balhblahblah

I've skipped a lot of details but I sure this is going to drawn enough
discussion. [Eg, how can a proxy can tell if a UAS will scrub the
record-route paaramters due to an older implementation?]

Cheers,

Robert.