Re: francois' comments and why RFC4474 not used in the field

When I am calling you, if I can discover that transcoding is required to 
establish the call, then I can establish a relationship with a 
transcoding service that I trust. If I use 3pcc to bring the transcoder 
into the call, then my call to you is still from *me*, and I vouch for 
the media source even if it is actually the transcoder. So the 
transcoding scheme can be as secure (or insecure) as any other. That of 
course assumes that the means for setting up the secured media session 
is something that can be set up using 3pcc without my necessarily having 
to relay the media.)

	Thanks,
	Paul

Dan Wing wrote:
>>> But if some service provider in the middle needs to drop the 
>>> call to <some spiffy codec> which isn't supported by Alice's 
>>> SP nor by Bob's SP -- what would that service provider do?  
>>> Not deploy that spiffy new codec, even though it would save 
>>> them thousands of dollars a day in satellite bandwidth fees?
>> Well, no. You just can't do end-to-end media security in this
>> case.
> 
> Ok.  Then in that case a way to downgrade to RTP -- which we need
> in any event -- would be needed.  
> 
>> I don't understdand at all the claim that if transcoding is 
>> allowed, there would be any point in doing media security, or
>> even Secure identity for that matter. I'm just saying if transcoding
>> or media mucking-around is allowed, then just stick with P-AI.
> 
> So that the victim (user2) can distinguish between a service provider doing
> transcoding for the legimate user1 versus the identity spoofing of user3
> (diagram taken from
> http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03):
> 
>                              user3/UA3
>                                   |
>                            +------+------+
>                            | enterprise3 |
>                            +------+------+
>                                   |
>               +----------+   +----+-----+   +----------+
>           +---+ SBC  SBC +---+ SBC  SBC +---+ SBC  SBC +---+
>           |   +----------+   +----------+   +----------+   |
>           |      ITSP-A         ITSP-B         ITSP-C      |
>           |                                                |
>    +------+------+                                  +------+------+
>    | enterprise1 |                                  | enterprise2 |
>    +------+------+                                  +------+------+
>           |                                                |
>      user1/UA1                                        user2/UA2
> 
> -d
> 
> _______________________________________________
> 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