Subject: RE: [SIP] Identification problem

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 3 Nov 2000 12:34:03 -0500

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

---

From: Neil Deason <[email-masked]>
Date: Fri, 03 Nov 2000 18:05:42 +0000

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

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

---

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

[snip]

> should return to the original notion of just using the list in the order you

I don't like this. We should stick to the basic principal 
that Request URIs refer to the addressed entity. Breaking
that would just create confusion. Though I do have a slight 
problem in that we already weaken the premise by allowing 
overloading of the port value within the hostport.

> the maddr and port in the URL.

There is a potential problem here and this looks like a 
reasonable solution. Pitty we can't extend it to all URLs.

Cheers,
Neil.

---

From: Sean Olson <[email-masked]>
Date: Mon, 06 Nov 2000 15:24:41 +0100

<snip>

> COmments? (I'm sure there are).

I like this approach except I would take it a step further and
do this for all URLs including SIP URLs. This allows maddr to go
back to its original intention for SIP URLs. Plus I hate special
cases; this seems (nominally) easier to implement.

/sean
--
Sean Olson <[email-masked]>
Ericsson Inc.

---

From: Bertil Engelholm <[email-masked]>
Date: Mon, 06 Nov 2000 15:25:39 +0100

> reasonable solution. Pitty we can't extend it to all URLs.

This is close to a solution I would like to have. I would
like to always have RR-parameters instead of URI-parameters.
The UA MUST always copy the complete RR-header(s) (including 
RR-parameters) into ROUTE. The UAS then take the contact/from
URI and copy it into ROUTE-URI. The only problem is to get the
RR-parameters back to the server that created them. Either
the servers have to copy the complete ROUTE header up as
request-URI (including the original RR-parameters) or the
ROUTE behaviour is changed so it behaves as VIA ie. a server
removes it's "own" ROUTE header instead of removing the next
servers ROUTE header. In this way you can add any parameters
you like in the RECORD-ROUTE and then get it back in ROUTE.

This is maybe to ask for too much but I beleave such a solution
would open up many new possibilities i.e. state transfer,
call state identification etc.  

/Bertil