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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 11 Jul 2001 05:21:11 -0700

Hi Jonathan,

I think this is a very interesting proposal that solves a few problems,
makes many things _much_ easier to implement and potentially more CPU
efficient - definitely a modest proposal worth considering.

I do however think that selection of the To & From tags must be done with
more care  if this suggestion is adopted (ie space & time uniqueness of tags
is more crucial). For instance, the UAS MUST always choose a To tag that is
different to the From tag so that the message direction can be determined.
Of course, if tags are chosen to be properly globally unique across space &
time (as they should be) then this is not a problem. 

Regards,

Robert.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 7:30 AM
> To: [email-masked]'
> Subject: [Sip] another modest proposal: change call-leg ID
> 
> 
> Folks,
> 
> While we're on the subject of modest proposals, here is 
> another that I've
> been toying with:
> 
>   Change the definition of call-leg ID. Instead of To, To-tag, From,
>   From-tag, and Call-ID, its *only* the tags and the Call-ID. That is,
>   the ID no longer contains the URLs.
> 
> There are quite a few benefits from this:
> 
> 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. 
> 
> 2. call-leg ID lookups in gateways are much faster now, since 
> the tags and
> call-ids are just strings. Matching is now case-sensitive 
> string compares.
> Much easier than URL comparison. 
> 
> 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.
> 
> 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.
> 
> 5. It works with existing proxies.
> 
> THe main drawback, of course, is that this won't interoperate 
> with rfc2543
> UAs. Thats fixable with Supported; the UAC indicates Supported:
> new-call-leg-id in the INVITE if it understands this. In that 
> case, any
> responses or re-invites that change the URLs include a Require:
> new-call-leg-id. 
> 
> I fully admit that this may not be worth the pain. However, 
> I'd welcome
> comments from others on whether its useful to consider further.
> 
> -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
> 

_______________________________________________
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: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 11 Jul 2001 07:42:48 -0600

This is a very good idea, IMHO. We have been struggling to find a
cleaner solution to some of the issues Jonathan mentions and additional
scenarios where it is difficult to preserve all elements of call-leg ID
as presently defined. In the long run, cleaning this up helps SIP
interoperability, so I think this is worth doing.  Is it too late to
include this in the bis draft?

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, July 11, 2001 12:30 AM
To: [email-masked]'
Subject: [Sip] another modest proposal: change call-leg ID

Folks,

While we're on the subject of modest proposals, here is another that
I've
been toying with:

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. 

2. call-leg ID lookups in gateways are much faster now, since the tags
and
call-ids are just strings. Matching is now case-sensitive string
compares.
Much easier than URL comparison. 

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.

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 main drawback, of course, is that this won't interoperate with
rfc2543
UAs. Thats fixable with Supported; the UAC indicates Supported:
new-call-leg-id in the INVITE if it understands this. In that case, any
responses or re-invites that change the URLs include a Require:
new-call-leg-id. 

I fully admit that this may not be worth the pain. However, I'd welcome
comments from others on whether its useful to consider further.

-Jonathan R.

---

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 11 Jul 2001 09:20:34 -0500

>Sent: Wednesday, July 11, 2001 1:30 AM
>To: [email-masked]'

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
is a nice thing to have.

>Much easier than URL comparison.

True. Of course, this wouldn't be an issue if the To:/From: were
immutable -- a modest proposal of my own :).

>new call leg, is that we needed to change the To field and the 
>request URI.

Does this mean a gateway will have to generate a new tag for
each endpoint it supports? 

>throw away the URLs. This shortens the header and makes matching of the

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.

>5. It works with existing proxies.

What about the overlapped dialing case?

>comments from others on whether its useful to consider further.

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

/sean

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 11 Jul 2001 10:32:31 -0600

Jonathan-

Would your proposal in any way enable a rogue endpoint to alter or take
over a session by replicating a valid set of Call-ID and tags? 

--Andy Zmolek

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, July 11, 2001 12:30 AM
To: [email-masked]'
Subject: [Sip] another modest proposal: change call-leg ID

Folks,

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Jul 2001 08:58:27 -0400

> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 8:21 AM
> To: 'Jonathan Rosenberg'; [email-masked]'
> Subject: RE: [Sip] another modest proposal: change call-leg ID
> 
> 
> Hi Jonathan,
> 

Right. Note that Call-ID is already supposed to be globally unique, which
helps. Choosing unique tags across space and time would also generally be
useful for other purposes.

-Jonathan R.
---

---

From: [email-masked]
Date: Wed, 11 Jul 2001 11:20:15 -0700

I think this is an excellent proposal. I support this.

While we are at it I would like to make another proposal, kind of related.
Currently call-ids unnecessarily contain the IP address of the client.
This gets into the way of hiding information in case of firewall
traversal. One easy way would be to md5 this or some function
that keeps the uniqueness of callid.

Shiv Haris
[email-masked]

At 02:30 AM 7/11/2001 -0400, Jonathan Rosenberg wrote:
>Folks,
>
>While we're on the subject of modest proposals, here is another that I've
>been toying with:
>
>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,
>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. 
>
>2. call-leg ID lookups in gateways are much faster now, since the tags and
>call-ids are just strings. Matching is now case-sensitive string compares.
>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.
>Replaces header to identify the entire call leg thats being replaced. This
>THe main drawback, of course, is that this won't interoperate with rfc2543

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 11 Jul 2001 14:40:33 -0700

Shiv,

Please reread bis-03. UA's concerned about revealing their identity are not
required to include their address. 

bis-3 says abotu Call-ID:

---

callid = token [ "@" token ]
Call-ID = ( "Call-ID" j "i" ) ":" callid

The callid MUST be a globally unique identifier and MUST NOT be reused for
later calls. Use of crypto-graphically random identifiers [28] is
RECOMMENDED. Implementations MAY use the form "localid@host". Call-IDs are
case-sensitive and are simply compared byte-by-byte.

---

Robert.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 7:20 PM
> To: Jonathan Rosenberg; [email-masked]'
> Subject: Re: [Sip] another modest proposal: change call-leg ID
> 
> 
>

---

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

> Sent: Wednesday, July 11, 2001 5:55 PM
> To: 'Jay Batson'; Zmolek, Andrew (Andrew); Jonathan Rosenberg
> Cc: Grothe, Lew E (Lew); [email-masked]
> I think people can always build rogue endpoints or proxies 
> but as far as I
> can see this proposal doesn't change the "security" 
> situation. 

Absolutely. Nothing changes as a result of this proposal.

> If the rogue
> entity can change/replicate the tag value then it could just as easily
> change/replicate the whole URL (and vice versa). Additionally if
> authentication is employed then the tag is just as protected 
> as the whole
> URL (since it is a subset).
>  
> It does however raise the point that if a message is signed then an
> intermediate proxy may not modify the rest of the URL (while 
> maintaining the
> same tag value) but I think this is a desirable rather than 
> undesirable
> property. [Just as a proxy may not currently change the 
> display name on a
> signed message even though this does not affect the call-leg id.]

Well, the proposal is not meant to support proxies modifying the To/From,
but rather, allow endpoints to change the To/From in the middle of the call.

-Jonathan R.

---

---

From: "Agboh, Charles" <[email-masked]>
Date: Thu, 12 Jul 2001 01:04:54 +0200

Hi,

I have a stupid question that may not be directly related to this
thread....How is the b2bua talking to the transcoder or are they co-located
in the same device?  If not then is it doing this using SIP or MGCP?   If it
is the latter then is this architecture (sorry) just another softswitch
MGC-type of device controlling an MG or is there more?

-Charles

> Sent: Wednesday, July 11, 2001 2:58 PM
> To: 'Fairlie-Cuninghame, Robert'; Jonathan Rosenberg; [email-masked]'