Subject: [SIP] Transaction Identification, once again

From: Bertil Engelholm <[email-masked]>
Date: Wed, 25 Oct 2000 18:58:17 +0200

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

---

From: Bertil Engelholm <[email-masked]>
Date: Mon, 30 Oct 2000 09:18:11 +0100

Sofar noone have commented this "problem".
So I send it again and hope someone can atleast say if 
it is regarded as a problem or if I have missed something.

/Bertil

---

From: "Agarwal, Aseem" <[email-masked]>
Date: Mon, 30 Oct 2000 16:36:01 -0800

Hi All,
        Discussions around this topic have cropped up a number of times.
I found related emails in q3 archives under the threads : "Transaction-Id",
"Loop detection again", "Late loop detection" and "Record-route and loop 
detection". However, the volume of emails involved and then the note on 
merged requests on the SIP Bake off site, have managed to obfuscate me.
    There is no clear example in the RFC or in the call flows RFC to
understand scenarios involved. I would appreciate if somebody could
provide example call flows or point me to text which further clarifies
these issues. I am sure providing example scenarios for :

  - loop detection 
  - detection and action on merged requests

will help the implementers and avoid further confusions.

rgds,
aseem

-----Original Message-----
From: Bertil Engelholm [mailto:[email-masked]]
Sent: Wednesday, October 25, 2000 9:58 AM
To: [email-masked]
Subject: [SIP] Transaction Identification, once again

Hi again,