Subject: RE: [Sip] Forking: a modest proposal.

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 11 Jul 2001 08:22:23 -0600

It is very tempting to depreciate forking altogether, especially when
one considers just how many value-added capabilities will have to be
implemented with B2BUA capabilities (forking with automatic bridging,
for instance). Simplifying the protocol here might be a very good thing,
but only if we can address the loop detection issue.

My own feeling is that keeping forking as it exists today isn't going to
result in fewer B2BUA implementations because of the value-add
temptation. If we're going to have looping, why not come up with a
scheme that works equally well with forking proxies and forked bridging
B2BUAs and other flavors still to be created?

What is the minimum amount of information required for loop detection?
Could we accomplish this by using a unique endpoint identifier like a
MAC address (although a large scale or applications UA might need to
append a tag to separate unique sub-entities for which it terminates
calls)? 

I believe there is a lot of value in providing for higher-level loop
detection regardless of our decision on forking. The real question is
whether standardized, higher-level loop detection is realistic or
feasible.

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

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 09, 2001 10:13 AM
To: 'Henning Schulzrinne'; Dean Willis
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] Forking: a modest proposal.

> From: Henning Schulzrinne [mailto:[email-masked]]
> 
> The problem is that once you implement "forking" at the B2B-UA level,
> you also need loop detection and most of the other features and pretty
> soon, you'll be back to where we started, one layer up, except that
> every system will implement them differently. It may well be that
> splitting them across two layers would've been the right thing, but I
> doubt that the overall system would be less complex. (I agree 
> that tags
> could be avoided if the B2BUA uses, say, a new call-ID for 
> each branch.)

I think it would be far less complex, since it doesn't impact every
silly little detail of every single extension. By making it an
application
on top of the protocol, it becomes an issue for the application
designer.
By and large, such a designer will be able to make reasonable decisions,
like: "I have no idea what method XYZZY means, so forking it would
be absurd."

Currently, since it is part of the spec, forking proxies will say
"XYZZY is just a method. I'm method agnostic. I'll fork it!"

I'm 100% behind Dean's proposal, and would be interested to see
how, say, a hum vote on the topic would turn out. Can we have a
short rant on this topic in London followed by a poll for rough
consensus?

/a

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Wed, 11 Jul 2001 07:52:59 -0700 (PDT)

The cost of B2BUA's is introducing a lot more
brittleness into the network. Sometimes this is
unavoidable, but when it isn't it shouldn't be
encouraged. The second line of defense here, IMO,
would be to just fail back to the UAC with lists
of candidates and let it sift through the
resulting graph.

	    Mike

Zmolek, Andrew (Andrew) writes:
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 6.0.4417.0">
 > <TITLE>RE: [Sip] Forking: a modest proposal.</TITLE>
 > </HEAD>
 > <BODY>
 > <!-- Converted from text/plain format -->
 > 
 > <P><FONT SIZE=2>It is very tempting to depreciate forking altogether, especially when one considers just how many value-added capabilities will have to be implemented with B2BUA capabilities (forking with automatic bridging, for instance). Simplifying the protocol here might be a very good thing, but only if we can address the loop detection issue.</FONT></P>
 > 
 > <P><FONT SIZE=2>My own feeling is that keeping forking as it exists today isn't going to result in fewer B2BUA implementations because of the value-add temptation. If we're going to have looping, why not come up with a scheme that works equally well with forking proxies and forked bridging B2BUAs and other flavors still to be created?</FONT></P>
 > 
 > <P><FONT SIZE=2>What is the minimum amount of information required for loop detection? Could we accomplish this by using a unique endpoint identifier like a MAC address (although a large scale or applications UA might need to append a tag to separate unique sub-entities for which it terminates calls)? </FONT></P>
 > 
 > <P><FONT SIZE=2>I believe there is a lot of value in providing for higher-level loop detection regardless of our decision on forking. The real question is whether standardized, higher-level loop detection is realistic or feasible.</FONT></P>
 > 
 > <P><FONT SIZE=2>--Andy Zmolek</FONT>
 > 
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Technology &amp; Standards Engineer</FONT>
 > 
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CTO Standards</FONT>
 > 
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Avaya Inc.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]</FONT>
 > 
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1 720 444 4001</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>-----Original Message-----</FONT>
 > 
 > <BR><FONT SIZE=2>From: [email-masked] [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
 > 
 > <BR><FONT SIZE=2>Sent: Monday, July 09, 2001 10:13 AM</FONT>
 > 
 > <BR><FONT SIZE=2>To: 'Henning Schulzrinne'; Dean Willis</FONT>
 > 
 > <BR><FONT SIZE=2>Cc: [email-masked]; [email-masked]</FONT>
 > 
 > <BR><FONT SIZE=2>Subject: RE: [Sip] Forking: a modest proposal.</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>&gt; From: Henning Schulzrinne [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
 > 
 > <BR><FONT SIZE=2>&gt; </FONT>
 > 
 > <BR><FONT SIZE=2>&gt; The problem is that once you implement &quot;forking&quot; at the B2B-UA level,</FONT>
 > 
 > <BR><FONT SIZE=2>&gt; you also need loop detection and most of the other features and pretty</FONT>
 > 
 > <BR><FONT SIZE=2>&gt; soon, you'll be back to where we started, one layer up, except that</FONT>
 > 
 > <BR><FONT SIZE=2>&gt; every system will implement them differently. It may well be that</FONT>
 > 
 > <BR><FONT SIZE=2>&gt; splitting them across two layers would've been the right thing, but I</FONT>
 > 
 > <BR><FONT SIZE=2>&gt; doubt that the overall system would be less complex. (I agree </FONT>
 > 
 > <BR><FONT SIZE=2>&gt; that tags</FONT>
 > 
 > <BR><FONT SIZE=2>&gt; could be avoided if the B2BUA uses, say, a new call-ID for </FONT>
 > 
 > <BR><FONT SIZE=2>&gt; each branch.)</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>I think it would be far less complex, since it doesn't impact every</FONT>
 > 
 > <BR><FONT SIZE=2>silly little detail of every single extension. By making it an application</FONT>
 > 
 > <BR><FONT SIZE=2>on top of the protocol, it becomes an issue for the application designer.</FONT>
 > 
 > <BR><FONT SIZE=2>By and large, such a designer will be able to make reasonable decisions,</FONT>
 > 
 > <BR><FONT SIZE=2>like: &quot;I have no idea what method XYZZY means, so forking it would</FONT>
 > 
 > <BR><FONT SIZE=2>be absurd.&quot;</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Currently, since it is part of the spec, forking proxies will say</FONT>
 > 
 > <BR><FONT SIZE=2>&quot;XYZZY is just a method. I'm method agnostic. I'll fork it!&quot;</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>I'm 100% behind Dean's proposal, and would be interested to see</FONT>
 > 
 > <BR><FONT SIZE=2>how, say, a hum vote on the topic would turn out. Can we have a</FONT>
 > 
 > <BR><FONT SIZE=2>short rant on this topic in London followed by a poll for rough</FONT>
 > 
 > <BR><FONT SIZE=2>consensus?</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>/a</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>_______________________________________________</FONT>
 > 
 > <BR><FONT SIZE=2>Sip mailing list&nbsp; <A HREF="http://www.ietf.org/mailman/listinfo/sip">http://www.ietf.org/mailman/listinfo/sip</A></FONT>
 > 
 > <BR><FONT SIZE=2>This list is for NEW development of the core SIP Protocol</FONT>
 > 
 > <BR><FONT SIZE=2>Use [email-masked] for questions on current sip</FONT>
 > 
 > <BR><FONT SIZE=2>Use [email-masked] for new developments on the application of sip</FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>