Re: [Sip] Thoughts on SIP Identity issues

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

Adam,

Thanks for your support. However, I do not accept transcoding as a use
case. To perform transcoding the service provider needs to decrypt and
re-encrypt, and therefore DTLS-SRTP will be terminated at the
transcoder. Therefore the service provider will indeed need to re-sign
the SIP request (the certificate fingerprint will have changed, among
other things), and the user will see that media is secure only as far as
the service provider. I think this is the correct outcome.

John

> -----Original Message-----
> From: Uzelac, Adam [mailto:Adam.Uzelac at globalcrossing.com] 
> Sent: 30 July 2008 12:06
> To: Cullen Jennings; Elwell, John
> Cc: SIP IETF
> Subject: RE: [Sip] Thoughts on SIP Identity issues
> 
> I believe that the problem statement (and associated use 
> cases) that John presented in the WG session are valid.  I 
> think it was unfortunate that those use cases couldn't be 
> discussed more in the WG session.  This email appears to me 
> simply John trying to further the discussions to bring out arguments.
> 
> One particular note I would like to share - given a comment 
> at the mic regarding 4474 working as designed and desired - 
> is that there are situations (good, bad or indifferent) that 
> necessitate changes in the SDP. John cited media steering as 
> a use case. Another use case is media steering for 
> transcoding.  Use case below:
> 
> Ent A--->SSP1--->Ent B
> 
> In this use case, Ent A and SSP1 have established certain 
> "rules of engagement", like G729, 2833, t.38, etc.  Ent B and 
> SSP1 have established their own "rules of engagement", for 
> instance G711 for voice, inband DTMF/FAX, etc.  Being there's 
> no common denominator for the media, the SDP in INVITE 
> "steers" to a device that can trancode.
> 
> Another use case, would be for those SSPs that have Lawful 
> Intercept requirements. Steering the media to something that 
> will can intercept should that be a regulatory obligation.
> 
> Adam
> 
> > -----Original Message-----
> > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> Behalf Of
> > Cullen Jennings
> > Sent: Tuesday, July 29, 2008 7:21 PM
> > To: Elwell, John
> > Cc: SIP IETF
> > Subject: Re: [Sip] Thoughts on SIP Identity issues
> >
> >
> > On Jul 29, 2008, at 17:53 , Elwell, John wrote:
> >
> > > Flawed argument 2:
> > > The problem exists when we go through service providers. Service
> > > providers use only E.164-based SIP URIs. We can't do 
> anything about
> > > E.164-based SIP URIs. Therefore we can't do anything to 
> address the
> > > case
> > > where the request goes through service providers. 
> Therefore there is
> > > nothing we can do.
> >
> >
> > Hmm, I don't think anyone made quite that argument. Personally, I'd
> > rather spend time thinking about the problems that were presented
> > today in the meeting than repeat previous discussions.
> >
> > Cullen <with my individual hat on>
> >
> > _______________________________________________
> > 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
> 
_______________________________________________
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