Re: Comment on DERIVE and B2BUAs

"Elwell, John" <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <0D5F89FAC29E2C41B98A6A762007F5D001382DE8@GBNTHT12009MSX.gb002.siemens.net>
 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Dan Wing
> Sent: 30 October 2008 02:21
> To: 'Iñaki Baz Castillo'; [email protected]
> 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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.