Subject: RE: [Sip] another modest proposal: change call-leg ID

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Jul 2001 19:14:20 -0400

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Wednesday, July 11, 2001 10:21 AM
To: 'Jonathan Rosenberg'; [email-masked]'
Subject: RE: [Sip] another modest proposal: change call-leg ID

>-----Original Message----- 
>From: Jonathan Rosenberg [mailto:[email-masked]] 
>Sent: Wednesday, July 11, 2001 1:30 AM 
>To: [email-masked]' 
>Subject: [Sip] another modest proposal: change call-leg ID 
> 
>>1. A calls B, and its forwarded to C. C accepts, and later 
>>re-INVITEs. The 
>>From field in this re-INVITE is NOT actually the identity of 
>>C, but rather, 
>>B. This screws up the idempotency of SIP INVITE. The From field has one 
>>meaning in INVITE, and another in re-INVITE. This makes 
>>defining policies 
>>based on the From field more complex, since they no longer 
>>work properly for 
>>re-INVITE. 
>
>But this proposal only removes information from the call leg ID, 
>which can't help you with this policy problem. You certainly 
>won't define policies based on tags. I agree this is 
>definitely a problem, but I don't think this is a solution. 
>There are also cases where you want to be able to identify a 
>session as being transferred -- having the original A/B parties 

No; the point is that when C sends a re-INVITE, it would place its own
address in the From field, rather than B's. This way, I could define a
policy like "reject requests with the domain foo.com", and this would work
sensibly for INVITEs and re-INVITEs alike, rather than it working for
re-INVITEs sometimes, depending on whether the call was forwarded.

>> 
>>3. Overlap dialing is easier. The reason we've had to send 
>>each digit as a 
>>new call leg, is that we needed to change the To field and the 
>>request URI. 
>>By definition, this meant a new call leg. Now, we can send all of that 
>>within a single call leg. Much cleaner. 
>
>Does this mean a gateway will have to generate a new tag for 
>each endpoint it supports? 

The gateway would need to generate a new tag for each call leg it accepts.
The idea is that tags should be globally unique across space and time.

>>4. The Replaces draft benefits. We've already identified a need for the 
>>Replaces header to identify the entire call leg thats being 
>>replaced. This 
>>gets big when it carries two URLs, two tags, and a call-id. Now, we can 
>>throw away the URLs. This shortens the header and makes matching of the 
>>call-leg IDs easier. 
>
>The replaces problem is simpler. You are talking about a pre-existing 
>call leg. This makes matching simpler and therefore the proposal of 
>using only the tags in this case is a reasonable one. The real 
>problem with using only tags is the *possibility* for clashes -- are 
>tags sufficiently unique? For Replaces:, I feel comfortable saying yes. 
>For the more general case, I'm not sure I do. 

Well, part of the proposal as I mention above is that tags should be
globally unqiue across space and time. Its just helpful for identifiers to
have this property, since you don't need to worry about clashes or horrible
special-case problems related to that.

> 
>>5. It works with existing proxies. 
>
>What about the overlapped dialing case? 

Sure, nothing has changed. For overlap, the updated digits come in new
transactions within the same call leg, rather than new call legs. This
doesn't change the fact that they are new transactions.

Now, as a corollary, the transaction ID can be alternatively defined as the
to tag, from tag, call-id, cseq, top via (branch id alone is actually
sufficient if computed as unique as well). If the branch ID is always there,
and is computed as a hash of the r-uri by the proxy which inserts it, then
you don't need to include the r-uri in the transaction ID, since its
effectively there through the via branch ID. This means transaction IDs can
also be URI-less. Just a thought.

>Does this have any impacts on the ways in which UAs allocate 
>tags? (esp. across restarts?) 

Yes. In all cases, tags really need to be globally unique across space and
time. If you want to survive across restarts, you also need to select tags
from some set X, such that there exists some indicator function F, for
which:

F(x) = 1, for x ELEMENT of X
F(x) = 0, for x not-ELEMENT of X

In other words, you can tell from the tag that it was created by this
instance of the proxy. A simple solution is to append a globally unqiue ID
with an instance ID. That has both the uniqueness property, and also meets
the requirement above.

We discussed this issue at the last IETF, and I proposed that wording to
this effect be included in the spec. The consensus, as I recall, was not to
include it, but rather, leave this additional computational aspect to
whatever extension deals with restarts (a draft is pending on that; I've
finished the first cut and it will be done before Friday). However, I think
the baseline requirement for global uniqueness across space/time should be
in bis itself. Other properties can augment that.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 13 Jul 2001 11:45:29 +0100

Jonathan wrote:
> sufficient if computed as unique as well).

I'm not sure that we currently mandate this (only the "second
part" is supposed to be globally unique, but this in itself is
not MUST).

> If the branch ID is 
> always there,
> and is computed as a hash of the r-uri by the proxy which inserts it,

Well, I know &:) of one implementation at least that does not
hash in the conventional sense...

> then
> effectively there through the via branch ID.

...but I think this will still hold.

> This means 
> transaction IDs can

Nice.  Although if a proxy was to take this approach, is it
possible it will expose it to an exploit where it will see
signalling that it thinks is for one call, but is in actual
fact for a different call (because (perhaps evil) UAs
sniff Call-IDs)?  It might well be that such proxies are
way too brittle if this is the case, just wanted to float.

Cheers,

 - Jo.