Subject: RE: Small rathole (was RE: [Sipping] Comment on request history d iscussion)

From: "Mark Watson"<[email-masked]>
Date: Tue, 19 Mar 2002 16:50:38 -0000

Robert,

I'm afraid I don't fully understand the loop detection mechanism, but what
it seemed to say was that the (second) request is matched against 'ongoing'
transactions.

Does that mean transactions for which a final response has not been sent, or
will there still be state after the final response has been sent (for 64*T1
seconds) ?

Is this state kept even if the final response was sent over reliable
transport ?

...Mark

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: 19 March 2002 16:27
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: [email-masked]; Sipping; Ben Campbell
> Subject: RE: Small rathole (was RE: [Sipping] Comment on 
> request history
> d iscussion)
> 
> 
> hmm - yes, I think you can construct some cases where you could make
> a single endpoint alert twice because it dropped state from the first
> round. For this to happen, you are talking about requests 
> arriving more
> than 64*T1 seconds apart.
> 
> RjS
> 
> On Tue, 2002-03-19 at 10:04, Mark Watson wrote:
> > Don't you only get 482 if a transaction is ongoing and a duplicate
> > request is received by another route ? 
> > 
> > The idea of the example was that the endpoints were being tried in
> > series, with each one only being attempted after the 
> previous one had
> > rejected the request.
> > 
> > Suppose the endpoint has finished processing the (first) transaction
> > i.e. it has rejected it for some reason, and as a result P1 has
> > forwarded the request to P2 which then tries the same endpoint again
> > (possibly some time later, having tried some other endpoints first).
> > 
> > In this case I'm not sure the endpoint will recognise this 
> as the same
> > request again, but I could be wrong! 
> > 
> > I can see this happening if I have (say) the equivalent of 
> hunt groups,
> > and some people are members of more than one group, but I'm 
> sure there
> > are more examples.
> > 
> > ...Mark 
> > 
> > 
> > 
> > 
> > 
> > > -----Original Message----- 
> > > From: Robert Sparks [ mailto:[email-masked]
> > <mailto:[email-masked]> ] 
> > > Sent: 19 March 2002 15:42 
> > > To: [email-masked] 
> > > Cc: Watson, Mark [MDN05:EP10:EXCH]; Sipping; Ben Campbell 
> > > Subject: Small rathole (was RE: [Sipping] Comment on 
> request history 
> > > discussion) 
> > > 
> > > 
> > > I'm curious about the motivation for that particular example 
> > > (P2 trying endpoints that P1 already tried). Why is this 
> compelling? 
> > > Basically, the only thing I can see coming from it is trading 
> > > processing 
> > > time at P2 for the network traffic of the second request to the 
> > > endpoint. That second request is going to be rejected 
> immediately with
> > 
> > > a 482 Merged. The UA is not going to alert and unless you 
> have broken 
> > > networks, it will not hold up a sequential search at P2 until 
> > > a timeout. 
> > > 
> > > Am I missing something? 
> > > 
> > > RjS 
> > > 
> > > On Tue, 2002-03-19 at 09:26, Eric Burger wrote: 
> > > > Since I was the person that stood up in London to say that 
> > > the "history" 
> > > > thing was application-specific, I formally eat my humble pie. 
> > > > 
> > > > The requirements proposed in 
> > > draft-watson-sipping-req-history-00.txt is 
> > > > EXACTLY the right thing to do.  I might offer that while 
> > > the draft is an 
> > > > infinite improvement on the last attempt at "history", some 
> > > verbiage on how 
> > > > it gets used may allay both fears and misunderstandings on 
> > > what it is about. 
> > > > An example, such as was offered in the presentation on 
> > > proxies re-attempting 
> > > > terminations that were attempted already, would go a long way. 
> > > > 
> > > > -----Original Message----- 
> > > > From: Mark Watson [ mailto:[email-masked]
> > <mailto:[email-masked]> ] 
> > > > Sent: Tuesday, March 19, 2002 8:48 AM 
> > > > To: [email-masked]'; Sipping 
> > > > Cc: Ben Campbell 
> > > > Subject: RE: [Sipping] Comment on request history discussion 
> > > > 
> > > > 
> > > > Eric, 
> > > > There is nothing PSTN-centric about the proposal. 
> > > > There is only one 'thing'/'event' which is proposed to be 
> > > recorded in the 
> > > > Request History information and that is retargetting of the 
> > > request (i.e. 
> > > > changing of the Request-URI), since it is this action 
> which causes 
> > > > information to be lost (namely the old Request-URI). I 
> > > think this is a 
> > > > fairly SIP-centric way of looking at the problem. 
> > > > 'Retargetting' can occur for very many reasons and we do 
> > > not propose that we 
> > > > standardise these as a fixed set - indeed this would be 
> > > against the spirit 
> > > > of SIP where we standardise capabilities, not end-user 
> services. 
> > > > We expect that many services can make use of the knowledge 
> > > of retargeting 
> > > > which has taken place without necessarily knowing *why* the 
> > > retargetting 
> > > > took place. 
> > > > Of course, there are a number of reasons why retargeting 
> > > takes place which 
> > > > are well-defined and common, and I see no harm in 
> > > standardising indications 
> > > > for these - and we can draw on the 'Reason' draft for this. 
> > > > Regards...Mark 
> > > > 
> > > > 
> > > > > -----Original Message----- 
> > > > > From: Eric Burger [ mailto:[email-masked]
> > <mailto:[email-masked]> ] 
> > > > > Sent: 19 March 2002 01:33 
> > > > > To: Sipping 
> > > > > Cc: Ben Campbell 
> > > > > Subject: RE: [Sipping] Comment on request history discussion 
> > > > > 
> > > > > 
> > > > > [Wow!  Ben & I strongly agree on something...] 
> > > > > 
> > > > > Seconding Ben's issue below, let's consider another 
> > > > > meta-issue.  *What* is 
> > > > > the thing (token, header, object) that gets passed 
> > > > > downstream?  By "what", I 
> > > > > don't mean the mechanics -- I mean the semantics.  The draft 
> > > > > and discussion 
> > > > > envision a set of things (one of tokens, headers, objects) 
> > > > > that describe 
> > > > > events like "I tried this address and it was busy", "I tried 
> > > > > this address 
> > > > > and it rejected me", "I got this call because another proxy 
> > > > > tried me", etc. 
> > > > > That is, a set of things like "addresses attempted", "result 
> > > > > busy/noanswer/forwarded/dnd", "next step tried". 
> > > > > 
> > > > > The problem is that this set of things is, by definition, 
> > > > > fixed.  Worse yet, 
> > > > > it assumes a PSTN-centric approach to call processing.  Every 
> > > > > time someone 
> > > > > comes up with a new way of doing call processing, we'd 
> > > need another 
> > > > > token/header/object.  I have visions of H.450.zzzzzz here! 
> > > > > Agents that 
> > > > > understand "history" would all need to understand that 
> > > new "thing" for 
> > > > > meaningful processing.  I don't see a meaningful default 
> > > action for 
> > > > > "history".  Worse yet, if the new thing is not a linear call 
> > > > > processing 
> > > > > method, e.g. "I checked the phase of the moon and Zephavra 
> > > > > sent an IM that 
> > > > > inclined the plane that upset the balance that moved me 
> > > to decide to 
> > > > > hand-off the call to you", it is not clear how a history 
> > > > > mechanism would 
> > > > > report that. 
> > > > > 
> > > > > -----Original Message----- 
> > > > > From: [email-masked] 
> > > > [ mailto:[email-masked] 
> <mailto:[email-masked]> ]On
> > Behalf Of 
> > > > Ben Campbell 
> > > > Sent: Monday, March 18, 2002 11:35 AM 
> > > > To: Sipping 
> > > > Subject: [Sipping] Comment on request history discussion 
> > > > 
> > > > 
> > > > Apologies for not airing this in the meeting--we ran out of 
> > > time on the 
> > > > subject just as I was figuring out how to word my concern. 
> > > > Robert and Dean (and others) pointed out the distinction 
> > > between a  core 
> > > > device telling a downstream device the history of a request 
> > > and letting it 
> > > > choose its behavior vs. the core device specifically 
> > > telling the downstream 
> > > > device what to do. 
> > > > In a voice mail example, the core device (I will assume it 
> > > is a proxy for 
> > > > the rest of this note) must make the decision to forward 
> > > the request to the 
> > > > voice mail server in the first place. That in itself 
> was a choice of
> > 
> > > > behavior. The history draft makes an implicit assumption 
> > > that the proxy 
> > > > knows that all voice mail like behavior goes to the same 
> > > device, that is, 
> > > > the history approach forces us into a certain service 
> decomposition.
> > 
> > > > But what if I want to build a voice mail service where busy 
> > > conditions and 
> > > > no-answer conditions result in forwarding to two 
> separate devices? 
> > > > IMO, the history approach in this particular application is 
> > > considerably 
> > > > _more_ limiting than the approach of allowing the proxy to 
> > > select the 
> > > > end-point behavior through a well selected URL. 
> > > > 
> > > > 
> > > > _______________________________________________ 
> > > > Sipping mailing list  
https://www1.ietf.org/mailman/listinfo/sipping
> <https://www1.ietf.org/mailman/listinfo/sipping>  
> > > This list is for NEW development of the application of SIP 
> > > Use [email-masked] for questions on current sip 
> > > Use [email-masked] for new developments of core SIP 
> > > 
> > > 
> > > _______________________________________________ 
> > > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> <https://www1.ietf.org/mailman/listinfo/sipping>  
> > > This list is for NEW development of the application of SIP 
> > > Use [email-masked] for questions on current sip 
> > > Use [email-masked] for new developments of core SIP 
> > > 
> > > 
> > > _______________________________________________ 
> > > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> <https://www1.ietf.org/mailman/listinfo/sipping>  
> > > This list is for NEW development of the application of SIP 
> > > Use [email-masked] for questions on current sip 
> > > Use [email-masked] for new developments of core SIP 
> > 
> > 
> > 
>

---

From: Robert Sparks <[email-masked]>
Date: 19 Mar 2002 11:13:11 -0600

On Tue, 2002-03-19 at 10:50, Mark Watson wrote:
> Robert, 
> 
> I'm afraid I don't fully understand the loop detection mechanism, but
> what it seemed to say was that the (second) request is matched against
> 'ongoing' transactions.
> 
> Does that mean transactions for which a final response has not been
> sent, or will there still be state after the final response has been
> sent (for 64*T1 seconds) ?
Well, as I corrected myself earlier, its 32s independent of T1, but its
not clear to me now that being in completed satisfies "in progress". As
you point out correctly, this is only for state machines on top of UDP
transports, so it was a dead-end anyhow.

Any correlation of the two requests would have to be done at the TU
layers and AFAI remember or can tell from a real quick reskim, the spec
doesn't talk about doing that.

So, I'll stand down on this point.

RjS

> <mailto:[email-masked]>  
> > > < mailto:[email-masked] <mailto:[email-masked]> >
> ] 
> <mailto:[email-masked]>  
> > > < mailto:[email-masked]
> <mailto:[email-masked]> > ] 
> <mailto:[email-masked]>  
> > > < mailto:[email-masked] <mailto:[email-masked]> > ] 
> > > > > [ mailto:[email-masked] <mailto:[email-masked]>
> 
> > < mailto:[email-masked] <mailto:[email-masked]> > ]On 
> > > Behalf Of 
> > > > > Ben Campbell 
> > < https://www1.ietf.org/mailman/listinfo/sipping
> <https://www1.ietf.org/mailman/listinfo/sipping> >  
> > < https://www1.ietf.org/mailman/listinfo/sipping
> <https://www1.ietf.org/mailman/listinfo/sipping> >  
> > < https://www1.ietf.org/mailman/listinfo/sipping
> <https://www1.ietf.org/mailman/listinfo/sipping> >