Re: FW: I-D Action:draft-kaplan-sip-session-id-00.txt

 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Hadriel Kaplan
> Sent: 02 December 2008 21:36
> To: Ian Elz
> Cc: SIP List
> Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
> 
> Hi Ian, comments inline...
> 
> > -----Original Message-----
> > From: Ian Elz [mailto:[email protected]]
> > Sent: Tuesday, December 02, 2008 6:22 AM
> >
> > My main comment on your draft at present is the proposal to allow a
> > proxy to insert the session-id header if it has not been 
> inserted by the
> > UA. I think that this introduces additional problems of how 
> to ensure
> > that the proxy in included in the message path of a new request that
> > uses the session-id that it inserted as a reference to the original
> > dialog.
> 
> You mean that a "Proxy" in particular could do this, right? 
> (not that a B2BUA could do this?)
> 
> Right now the draft is written to make the matching mechanics 
> basically optional for a node.  The Session-ID header has 
> uses beyond dialog matching ones, and I prefer to keep the 
> bar low for implementations to at least pass it through, or 
> even generate it.  You're right that a Proxy implementing the 
> matching function would need to keep itself in the path - 
> good catch - I will add it if we decide Proxies should be 
> able to do the matching function.  (and yes, it could only 
> keep itself in the path in certain scenarios, so we may just 
> not want to let Proxies do a matching function period to make 
> the draft easier to comprehend)
> 
> 
> > This requires 2 things:
> > (1) that every B2BUA constantly be upgraded to handle whatever new
> > mechanism's syntax is for the identifiers, every time a new one is
> > defined. (e.g., new XML schema or new header)  I realize that's the
> > nature of "you break it, you fix it", but if people want to 
> have their
> > new thing work without needing B2BUA's to be upgraded or 
> re-configured,
> > then there needs to be some generic way of handling this.
> > (2) that the mechanism using the call-id+tags gets sent to the B2BUA
> > that changed them.  Often it will.  Sometimes it can't.  
> For example,
> > the mediactrl-framework model.  Stick a b2bua between the UA and the
> > Media-Control-Client, and the application doesn't work - or wouldn't
> > have, except they changed it to use a new identifier different from
> > call-id to avoid this problem.
> >
> > [Ian Elz ] (1) is an issue with B2BUAs. Xavier's b2bua draft was an
> > attempt to give some guidance on how B2BUAs should behave 
> to make them
> > as proxy like as possible.
> 
> Yes, and my own product does that as well by default (dialog 
> transparency).  Many/most operators turn that off when they 
> install it, fwiw.  But this isn't really about SBC's.  If it 
> were only about SBC's, there would be other ways to skin this 
> cat.  The problem is all B2BUA's.  The number of B2BUA 
> vendors/products/types is scary.  Most of them seem to change 
> Call-ID+tag's all the time, for reasons only they know.  I 
> know it's not due to the security issues.  I know some of 
> them change them to handle spirals correctly.  I know some of 
> them change them for internal architecture reasons.  But I 
> don't know all the reasons.  I can't speak for them.
[JRE] One reason is 3PCC behaviour. Suppose the B2BUA does 3PCC attended
call transfer, i.e., it wants to join together two existing calls, each
with its own call-ID. The resulting call will have different call-IDs on
either side of the B2BUA, even if the original calls had only a single
call-ID each.

John
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip