Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01

[Hadriel Kaplan <[e-mail]>]

> -----Original Message-----
> From: Leis, Peter (NSN - DE/Munich) [mailto:[e-mail]]
> Sent: Friday, April 30, 2010 4:17 AM
> To: Hadriel Kaplan; Dawes, Peter, VF-Group; [e-mail]
> 
> > -----Original Message-----
> > From: ext Hadriel Kaplan [mailto:[e-mail]]
> > Sent: Thursday, April 29, 2010 6:59 PM
> >
> > Right, but I'm trying to figure out why that is.  I mean
> > what's the reason the UA needs to know at Registration time
> > that it's next-hop b2bua can do srtp, instead of letting SDP
> > handle it?
> >
> > I *think* the answer is so that it can later send an INVITE
> > with an SDP offer without failing the request - is that the reason?
> 
> Right
 
OK, and I also agree that's a real problem.  That issue was raised in the IETF in 2006/2007.  There was a very simple proposal to avoid that, in draft-kaplan-mmusic-best-effort-srtp, but the decision of the MMUSIC WG was to instead use draft-ietf-mmusic-sdp-capability-negotiation to accomplish it.  That draft is now in the RFC editor's queue.  I know it's a lot of processing overhead, but that was the decision.  And I think 3gpp has put support for that into some release or other.


> > > RFC 3840 does only cover UA indicating support, but not SBC
> > indicating
> > > support.
> >
> > Actually, in a way it does.  An SBC is a B2BUA.  As a UA, it
> > can indicate feature tags.  What it *can't* do is indicate it
> > in the REGISTER response it sends to the UA.  But the UA
> > could send an OPTIONS to the B2BUA and get it in a feature
> > tag of the response to the OPTIONS.  I know it sucks to send
> > more SIP messages, but I don't see how to avoid that and be
> > consistent with the SIP architecture.  It's really weird for
> > a REGISTER response to indicate media capabilities of the Registrar.
> 
> use of OPTIONS was discussed, but due to the additional signalling, it
> was discarded.

Considering all of the other signaling already required (subscription to reg-event, subscription to presence, xcap, possibly subscription to Config server) isn't an OPTIONS just a nit at this point?  And that way this could be a general solution, instead of a 3gpp-specific one.


> The indication of network support for SDES-SRTP in response to REGISTER
> is not included by the registrar, but by the network element placed at
> the edge (the SBC/B2BUA)

I know, but from the UA's perspective the REGISTER response is coming from the Registrar, possibly through proxies.  There's no logical/conceptual model in the IETF for a REGISTER response to indicate media capabilities of some middle hop of the REGISTER.

-hadriel