Subject: [SIP] Replaces leg matching (was Re: [Sip-implementors] replaces)

From: Billy Biggs <[email-masked]>
Date: Sat, 9 Jun 2001 00:47:36 -0400

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).

> The only other argument that I've heard that could sway me is that if
> this actual situation was encountered in the real world, the result
> would be disaster.  If a Gateway replaces the wrong session, then the
> wrong session will be dropped and two parties that had no intention of
> talking will suddenly be connected - a very hard thing to explain to
> your customers!

  I see this as the best argument for including the full call leg
identification.

> Wouldn't a MD5 hash of specific parts of the To and From headers
> (user, host, port, and tags, with rules for default handling) answer
> your concerns about URL escaping and header size and eliminate the
> possibility of the wrong session being replaced?

  If only a subset of the information in the To and From is required for
the hash, is this any better than just the tags?  A call-leg matches
when the full URI including parameters and all header parameters match.
So, to _always_ match correctly, we must be complete.

  The problem then becomes one of debugging.  We need to decide on a
canonical form of a URI for conversions (remove all spaces and line
folding, lower case everything you can, make sure you watch for quotes,
careful for invalid URIs, etc etc), and then hope nobody messes up.  If
someone's phone is sending Replaces headers which don't work and a
customer complains, it's difficult to figure who's phone is broken,
since all you have is the hash.

  This may be an acceptable loss, since Replaces has the nice property
that if things do go wrong and everyone has multi-line phones, the
transfer will work fine, but somebody's phone may ring unexpectedly.

  I'd rather just stick with the tags.

> My main concern is that we finish this discussion now so that we can
> finalize the attended transfer call flows now that REFER seems to be
> stable.

  I'd definitely like to see this issue closed.  More thoughts
appreciated.

> Billy Biggs wrote:
> 
> > Dvir Oren ([email-masked]):
> >
> > > Are the tags in 'to' and 'from' plus the call-id sufficient to
> > > find a call-leg?  It appears from the replaces draft that this is
> > > all is needed.  However, at least in my implementation, I also
> > > need the 'to' and 'from' themselves, and not only the tags.
> >
> >   It's unclear to my why you feel so strongly about needing the full
> > to and from headers.
> >
> >   In almost all cases, the call-id alone should be sufficient to
> > identify an active call.  For Replaces, the only cases I can think
> > of where the call-id might be insufficient are:
> >
> >   a) Two UAs answer the same call and both are accepted.  When an
> >      INVITE arrives with a replaces, there is a possibility that
> >      both UAs receive the INVITE (some transparent proxy may have
> >      decided to fork it).  In this case, the UAs each check to see
> >      who's tags are listed to determine if they should honour the
> >      Replaces.
> >
> >   b) Some broken UA makes many calls under the same call-id.  In
> >      this case, checking the tags is a cheap way of identifying
> >      which call was intended.
> >
> >   Clearly in these cases, having the tags is useful, and having the
> > full to and from would be more 'correct' (but AFAICT not, as you
> > claim, required).  My reason for just using the tags is a
> > practical one:  if the full to and from are used, the escaping and
> > unescaping gets much worse for very little gain, and we've also
> > greatly increased the length of the header.
> >
> >   I worry about:
> >   Replaces: [email-masked];to=[email-masked]%3bmobileid%3d9775
> >                                       ;to-tag=88f787f
> >
> >   from:
> >   Refer-To: sip:[email-masked]?
> >             Replaces=[email-masked][email-masked]
> >                      %253bmobileid%253d9775%3dto-tag%3d88f787f
> >
> >   Where double-escape code decoding is required.

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

_______________________________________________
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: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 25 Jun 2001 17:38:02 -0400

It was agreed at the Interim SIP meeting in Feb. that is was
legal to create calls using the same call-id.  (i.e. on a conference
bridge).  There is no semantics assumed, it is just another call
as long as the To or From field differ.
http://www.softarmor.com/sipwg/meets/interim-feb-01/notes/dwillis.html
Has this decision changed somewhere along the line?

So call-id by itself is not sufficient.  Tags are optional in some cases
of RFC2543.  So how do we ensure uniqueness:
1) Require 2543-bis for Replaces (i.e. MUST have To & From tags)
or
2) Require at least the user-id, host, port, tag parts of the To & From
    fields

---

From: Billy Biggs <[email-masked]>
Date: Mon, 25 Jun 2001 21:57:43 -0400

Daniel G. Petrie ([email-masked]):

> It was agreed at the Interim SIP meeting in Feb. that is was legal to
> create calls using the same call-id.  (i.e. on a conference bridge).
> There is no semantics assumed, it is just another call as long as the
> To or From field differ.

  Great.  Sure hope they use a new tag on their end. :)

> So call-id by itself is not sufficient.  Tags are optional in some
> cases of RFC2543.  So how do we ensure uniqueness:

  I like this option best.

> 2) Require at least the user-id, host, port, tag parts of the To &
>    From fields

  Unfortunately, the full to and from are needed for leg matching.  If
we're only going to go part way, why not settle with the tags.  I'd like
to hear a few more opinions though.