Subject: RE: [SIP] Replaces leg matching (was Re: [Sip-implementors] repla ces)

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Jun 2001 02:18:01 -0400

> -----Original Message-----
> From: Billy Biggs [mailto:[email-masked]]
> Sent: Saturday, June 09, 2001 12:48 AM
> To: Alan Johnston
> Cc: Dvir Oren; SIP Implementors; SIP List
> Subject: [SIP] Replaces leg matching (was Re: [Sip-implementors]
> replaces)
> 
> 
>   Alan,
> 
>   I'm posting this to the SIP WG list as well to solicit more 
> opinions.
> 
> > I know others have been thinking about whether we need the 
> full To and
> > From URLs (or a MD5 hash of them) in the Replaces header.  I'm not
> > convinced myself, but there is one possible scenario that 
> could cause
> > trouble.  A RFC2543 UAC which is redirected directly to another
> > RFC2543 UAS (no proxies in between) could result in a call 
> without any
> > tags (To tags are not mandatory in RFC2543 unless there are 
> more than
> > one Via headers, ie a proxy in the path).  Now, we are down 
> to relying
> > only on the uniqueness of the Call-ID.  Of course, any bis 
> UA will use
> > From and To tags.
> 
>   Since the Call-ID is unique, I don't see a matching problem.  We can
> also recommend that any UA which supports Replaces must also support
> bis (at least use tags).

Another practical issue worth considering is that many implementations in
gateways store call leg objects indexed by the hash of the call leg ID.
There is no direct index of calls based on call-id, since its really not
needed. Therefore, it becomes a practical problem to find the matching call
leg with just the call-id.

-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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Alan Johnston <[email-masked]>
Date: Tue, 12 Jun 2001 12:12:16 -0500

(Moved to the new SIP List)

Jonathan & Billy,

See my comments below.

Alan.

> > also recommend that any UA which supports Replaces must also support

Sounds like a reasonable solution.

> leg with just the call-id.

This practical issue is an important one.

I was actually leaning the other way, thinking that the Call-ID would make it
easier to index than the hash of the call leg information, but perhaps you are
right - if the hash function was identical to the one already used by the
Gateway to identify calls, this would seem to make the most sense.

I'd be interested in hearing from Gateway vendors, Conference Bridge vendors,
or anyone else who implements large shared UAs on this issue.

_______________________________________________
Sip mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: Billy Biggs <[email-masked]>
Date: Tue, 26 Jun 2001 00:26:55 -0400

Jonathan Rosenberg ([email-masked]):

> >   Since the Call-ID is unique, I don't see a matching problem.  We
> > can also recommend that any UA which supports Replaces must also
> > support bis (at least use tags).
> 
> Another practical issue worth considering is that many implementations
> in gateways store call leg objects indexed by the hash of the call leg
> ID.  There is no direct index of calls based on call-id, since its
> really not needed. Therefore, it becomes a practical problem to find
> the matching call leg with just the call-id.

  This would be solved by having the full to and from in the header, but
putting instead a hash would just mean standardizing the hash function
used by gateways, or force them to index by another hash.

  If we're forcing them to index on another hash, I'd rather just let
that be the call-id + tags.

  Nasty situation regardless.

-- 
Billy Biggs                     [email-masked]
http://www.billybiggs.com/      [email-masked]