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 PROTECTED]): > > > > > 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 PROTECTED];[EMAIL PROTECTED]%3bmobileid%3d9775 > > ;to-tag=88f787f > > > > from: > > Refer-To: sip:[EMAIL PROTECTED]? > > [EMAIL PROTECTED][EMAIL PROTECTED] > > %253bmobileid%253d9775%3dto-tag%3d88f787f > > > > Where double-escape code decoding is required. -- Billy Biggs [EMAIL PROTECTED] http://www.billybiggs.com/ [EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
