This is handled better if one of the UAs arranges for the transcoding,
as specified in the RFC (number escapes me) that describes that.
Then, any integrity issues about the media are at the discretion of the
UA that set it up. And in this case it presents no identity or signing
issues.
Paul
Dean Willis wrote:
On Jul 30, 2008, at 12:05 PM, Uzelac, Adam wrote:
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.
This is more that sterring; the media is being terminated at a device
that transcodes it. Then a new media stream flows out the other side.
When media transcoding is occurring, media integrity is hop-by-hop. I
maintain that we have no need for an end-to-end identity representation
when the media itself is hop by hop.
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.
Same as above. Although one should note that proper use of DTLS-SRTP to
detect the lawful intercept.
--
Dean
_______________________________________________
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
