Subject: RE: [Sip] another modest proposal: change call-leg ID

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 13 Jul 2001 04:55:08 -0700

Hi Jo,

> Eeek!  I think this might be A Bridge Too Far.  Okay,
> I guess that proxies could unwind any From (/ To) changes
> they made as responses swam back, but this is going to
> break loop detection and request-merge detection and
> I can imagine lots more with proxies that don't know these
> new rules, if nothing else.  Just seems a little bit too
> much of a leap to me.

Thanks for the response.

Yeah, I definitely think that regardless of whether my addition is deemed a
good idea or not we should consider JR's original suggestion independently. 

That was something I meant to add. The proxy would be required to remain
call stateful (ie, the proxy would have to record-route) and unwind any
changes it made to the To/From for this suggestion to be compatible with
older proxies. Perhaps this is too great a burden to accept? (A Bridge Too
Far). I still think it does have advantages though in my mind. People will
do this sort of thing anyway except they may probably just use a full blown
B2BUA instead - at least with this approach the two UA's can correlate the
call-id in their CDR's.

I've thought about the loop detection before I made the suggestion and I
can't see it breaks it. Older proxies won't detect the loop (because they
will see each instance as a separate call - which doesn't break anything)
but given that the loop must include a proxy that does support the looser
call-id definition (otherwise it wouldn't be loop) then the loop detection
will be made. Right?

Robert.

> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Friday, July 13, 2001 12:22 PM
> To: Fairlie-Cuninghame, Robert; 'Jonathan Rosenberg'
> Cc: [email-masked]
> Subject: RE: [Sip] another modest proposal: change call-leg ID
> 
> 
> Robert wrote:
> > Jonathan wrote:
> > > Well, the proposal is not meant to support proxies modifying
> > > the To/From,
> > > but rather, allow endpoints to change the To/From in the
> > > middle of the call.
> > >
> > Hi Jonathan,
> >
> > Perhaps not but I think it could it be used for such a 
> purpose with _huge_
> > advantage (especially in telephony applications) and yet 
> without being too
> > open to wholesale abuse. It may also deprecate some of the 
> reasons that
> > people are using B2BUA-like devices merely so that they can 
> rewrite the
> > To/From fields (for subscriber identity hiding). [Where 
> transport-layer
> > identity screening is not important, eg, on a multi-user server
> > or gateway.]
> [...]
> 
> Eeek!  I think this might be A Bridge Too Far.  Okay,
> I guess that proxies could unwind any From (/ To) changes
> they made as responses swam back, but this is going to
> break loop detection and request-merge detection and
> I can imagine lots more with proxies that don't know these
> new rules, if nothing else.  Just seems a little bit too
> much of a leap to me.
> 
> 
>  - Jo.
> 

_______________________________________________
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: "Jo Hornsby" <[email-masked]>
Date: Fri, 13 Jul 2001 16:55:31 +0100

Robert wrote:
> older proxies.

No, I don't think that call statefulness is required.
It just needs to unwind on a transaction basis.  (If
you're thinking that call statefulness could enable
it to "resume" the original From / To on a re-INVITE,
think what a downstream Record-Routed proxy would
see on a re-INVITE from the callee....)

> Perhaps this is too great a burden to accept? (A Bridge Too
> Far). I still think it does have advantages though in my mind.

Oh yeah, I can see advantages, but I feel it's a
little bit too brittle: playing with such fundamental
headers now.

> Peoplewill

True, true.  Didn't think it through enough.

 - Jo.