Subject: RE: [SIP] Identification problem

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 3 Nov 2000 13:36:36 -0500

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Friday, November 03, 2000 1:06 PM
> To: Jonathan Rosenberg
> Cc: 'Bertil Engelholm'; [email-masked]
> Subject: Re: [SIP] Identification problem
> 
> 
> Aplogies for a rushed post but I thought we had this
> covered already with the bis-02 introduction of global
> unique via branch param.
> 
> http://lists.bell-labs.com/pipermail/sip/2000q3/002635.html
> 
> Am I missing the problem? The other RR suggestions are 
> certainly interesting ;)

The problem is that the unique via branch param allows you to
*differentiate* between each request, but there is no easy way to know that
a request corresponds to a specific state machine. Thats because (1) the
proxy immediately before and/or after P1 may not actually record-route, so
the branch param in the original INVITE could be totally different from the
one in the re-INVITE or BYE, and (2) proxy P1 has no way to know what the
branch param for requests in the REVERSE direction will look like after the
original INVITE.

-Jonathan R.

> 
> Cheers,
> Neil.
> -- 
> Ubiquity Software Corporation, UK        http://www.ubiquity.net
> 
> 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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
> 

---
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

---

From: Neil Deason <[email-masked]>
Date: Mon, 06 Nov 2000 10:14:07 +0000

> branch param for requests in the REVERSE direction will look like after the

I agree there is this issue but is it really a problem for 
the spec? I saw this as just one of the additional challenges 
faced by a Proxy wishing to be call stateful. It isn't easy but 
I think it is already solvable without requiring further addition 
to the spec. If there is a neat solution that adds something more 
if everybody follows it then we should add it. If not we don't 
need more text.

Cheers,
Neil.