Re: [Sip] Comment on DERIVE and B2BUAs

["Elwell, John" <john.elwell at siemens.com>]

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> Behalf Of Dan Wing
> Sent: 30 October 2008 02:21
> To: 'Iñaki Baz Castillo'; sip at ietf.org
> Subject: Re: [Sip] Comment on DERIVE and B2BUAs
> 
> > El Miércoles, 29 de Octubre de 2008, Dan Wing escribió:
> > > > Would the SBC not have to handle the SUBSCRIBE request 
> > locally? After
> > > > all, since it is a terminal UA for the call, it also knows
> > > > about all the
> > > > dialog states. The end-user UA would never even see the 
> SUBSCRIBE.
> > >
> > > If that's a problem, just use some different method that 
> goes end to
> > > end.  The always-loved INFO comes to mind.
> > 
> > Anyway, you need to carry in the INFO body (or headers) data 
> > about the current 
> > dialog, but this data changes in both legs of the B2BUA, so 
> > it will fail.
> > It's exactly the same case as if the SUBSCRIBE is "forwarded" 
> > between B2BUA 
> > legs without replacing the dialog data (from leg B to leg A).
> 
> And that is why there are two proposals that use something that
> can't change -- the certificate fingerprint of the endpoint:
> 
>   draft-fischer-sip-e2e-sec-media (expired)
>   draft-wing-sip-identity-media (expired)
> 
> They expired due to lack of interest.
> 
> 
> Let's talk about the meta-issue:  do we want assurance of a 
> "From:" over SBCs?  If so, let us please convince the ADs 
> in Minneapolis and let us please get a new SIP milestone.
[JRE] Agreed. DERIVE (or something derived from it) would then be one of the candidates.

John

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip