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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
