Subject: [SIP] Identification problem

From: Bertil Engelholm <[email-masked]>
Date: Fri, 03 Nov 2000 16:53:51 +0100

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.

Since noone have given any solutions I'll give my view 
of what I beleave could be done.

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 ?

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

---

From: Sean Olson <[email-masked]>
Date: Fri, 03 Nov 2000 17:13:36 +0100

Bertil Engelholm wrote:

<snip>

> have been discussed for states ?

I was under the impression that the Record-Route was supposed
to be copied in its entirety to Route: (with some modifications, but
no exclusion of parameters).  I don't see anything in section 6.34
about the exclusion of parameters other than the fact that proxies
should not include a transport parameter.

On the topic of states, I would prefer to see the use of the
State: header for this purpose since it is more generic.
You do point out one case where state/context information could
be useful.

/sean

---

From: Neil Deason <[email-masked]>
Date: Fri, 03 Nov 2000 17:26:47 +0000

I am afraid I don't see a problem with the spec. Unless I 
am missing something what you are talking about is a call 
stateful proxy not just a plain transaction stateful one. 
The transaction stateful one is OK as the bis-02 change to 
make the Via branch param globally unique differentiates 
the otherwise isomorphic BYEs. A call stateful proxy needs 
to do accounting beyond proxy transaction state, e.g.To/From 
tags. This accounting will also need to cover matching the 
right call state machine to the right BYE. For example on a 
reverse leg BYE the call state machine created 2nd will get 
the BYE 1st.

BTW the issues raised in the solutions have been raised 
before see the threads "Record-Route and maddr" and 
"transaction identification". Introducing the contemplated 
State header is a cleaner way of achieving the 2nd solution.

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