Re: [Sip] draft-kuthan-sip-derive

> -----Original Message-----
> From: Jiri Kuthan [mailto:jiri@iptel.org] 
> Sent: 17 November 2008 13:20
> To: Hadriel Kaplan
> Cc: Dan Wing; 'Adam Roach'; Dorgham.Sisalem@tekelec.com; 'SIP 
> IETF'; Raphael.Coeffic@tekelec.com; Elwell, John; 
> Jiri.Kuthan@tekelec.com; Victor.Pascual@tekelec.com
> Subject: Re: [Sip] draft-kuthan-sip-derive
> 
> Hadriel Kaplan wrote:
> > 
> >> -----Original Message-----
> >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] 
> On Behalf Of Jiri
> >> Kuthan
> >> Sent: Sunday, November 16, 2008 5:54 PM
> >> To: Dan Wing
> >>
> >> Aside from architectural and evolution arguments on both a 
> and b, does
> >> anyone
> >> have an opinion on what can safely get through the B2BUAs?
> > 
> > Audio.  :)
> > Whatever you choose, don't use the call-id or tags.
> 
> :)
> 
> well, this is really guessing which can be quite brittle but 
> isn't dialog
> id safer? For lot of other things to function, it must be translated
> consistently from A to X on one side and X to A in the 
> reverse direction,
> mustn't it? So that using some method with same callid/tags 
> as the tested
> INVITE should get to the same place?
[JRE] It requires the B2BUA to modify the contents of the SUBSCRIBE and
NOTIFY bodies. If B2BUAs would do this, that would work. The problem I
see is that a non-compliant B2BUA might act as UAS for the SUBSCRIBE
request and send back a NOTIFY with its own dialog information. It only
proves that the call has come from that B2BUA, which doesn't mean much.
How does the callee UA distinguish this unhelpful case from the helpful
case where the SUBSCRIBE request has been relayed all the way back to
the caller's UA (or at least the caller's domain) and the NOTIFY comes
from there? I guess it falls back to using RFC 4474 to sign the NOTIFY
request. But then a NOTIFY request signed by the local domain's B2BUA is
unhelpful, and a NOTIFY request from the caller's UA or its domain
proxy/B2BUA would have its signature broken by intervening B2BUAs. So we
are back where we started.

I suppose we have two seemingly incompatible requirements:
- it must work through any "reasonable" B2BUA behaviour in such a way
that the callee UA can detect whether e2e return routability has been
achieved;
- it must work without modifications to existing caller UAs.

If it is indeed impossible to satisfy both requirements, then which of
these is more important?

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@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip