Subject: RE: [Sip] Open Issue #140: use only tags for Call-leg ID

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 6 Dec 2001 02:25:48 -0500

Yes, you are correct.

Thanks for pointing that out.

-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

> -----Original Message-----
> From: Arunachalam Venkatraman [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 11:37 PM
> To: Jonathan Rosenberg; [email-masked]
> Subject: Re: [Sip] Open Issue #140: use only tags for Call-leg ID
> 
> 
> Jonathan
> I think you meant to say
> So, C(not B) could include its actual URL in the From field of the
> re-INVITE.
> Venkat
> 
> ----- Original Message -----
> From: "Jonathan Rosenberg" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, December 05, 2001 9:32 PM
> Subject: [Sip] Open Issue #140: use only tags for Call-leg ID
> 
> 
> > Issue:
> >
> > An interesting proposal is to modify the definition of 
> call-leg, so that
> is
> > the
> > to tag, from tag, and call-id. This is different from the current
> definition
> > in
> > that the URLs are dropped.
> >
> > Discussion:
> >
> > This approach has some important benefits:
> >
> > 1. overlap dialing now becomes easier. Each digit can be added as a
> > re-invite
> > with in the same call-leg (assuming re-invites can be sent 
> within a call
> leg
> >
> > before the previous completes - thats another issue) but 
> with a different
> > To/R-uri. Since the To URL is not part of the call-leg ID 
> process, this
> new
> > request can be part of the same call leg. However, the 
> current proposal is
> > to not allow overllaping INVITE, so this may be moot.
> >
> > 2. A invites B, which is proxied to C. C sends a re-INVITE 
> back to A. The
> > From
> > field in the request from C is wrong! We'd like to maintain the
> idempotency
> > of
> > INVITE, so that the from field is always the logical identity of the
> caller,
> > no
> > matter when its sent. So, B could include its actual URL in 
> the From field
> > of the re-INVITE. Since the call leg ID is based only on 
> tags, this would
> > work.
> >
> > 3. Call leg lookups are now oodles easier, since they are 
> just based on
> > case-sensitive string compares. No more messy URL 
> comparisons. However,
> its
> > worth noting that you can still do this anyway, since tags 
> have to be
> > globally unique. That is, even though the spec says its the full
> > To/From/Call-ID, you could just use tags/Call-ID to index 
> legs at a UA.
> What
> > you wouldn't be able to do is change the From/To URLs in subsequent
> > requests, as above in (2).
> >
> > 4. The Replaces header gets shortened; its now easier to 
> identify the call
> > leg
> > thats getting replaced. May not be a big deal.
> >
> > 5. This may work with existing proxies, but has 
> compatibility issues with
> > existing
> > UAs. A simple SUpported token would handle this, though.
> >
> >
> > Given that (1) is moot, (3) is possible without this 
> proposal, (4) is not
> > too important, the only real benefit is (2), that you can 
> send the right
> > From header in a re-INVITE. Now, an argument here is that 
> anybody who
> makes
> > policy decisions based on the From header anyway is in 
> trouble, since its
> > client supplied. Thus, you need to authenticate, and the credentials
> > provided (or the Remote-Party-ID header) are what you would 
> use anyway.
> So,
> > who cares if the From header is not right in the re-INVITE anyway.
> >
> > Proposal:
> >
> > So, given the limited utility, and the potential interop 
> problems, the
> > proposal is to keep the current wording.
> >
> > -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://www1.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://www1.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: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 10 Dec 2001 15:14:40 -0800

> thats getting replaced. May not be a big deal.

The Replaces header only needs to identify a unique call - not create it -
so even with the current dialog wording, the Replaces header can still
specify only Call-id, Lcoal-tag and remote-tag. 

Implementing Replaces is a different matter to changing proxy behaviors and
dialog identity - so backwards compatibility is not a problem. To tags
(generated by caller) and call-id (generated by caller) have always supposed
to have been globally unique and so should always identify session uniquely.

I guess there is the lookup problem where a UA is designed such that it can
_only_ lookup a call record if it has the full To & From URL's but I doubt
this is a realistic concern. Any UA supporting Replaces should hopefully be
fairly sophisticated and up-to-date.

Placing URL's in the Replaces header just makes everything that much larger
and more complicated. 

Regards,

Robert.