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

Dan Wing wrote:
>  
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email protected]] 
>> Sent: Friday, April 03, 2009 8:56 PM
>> To: Dan Wing
>> Cc: 'Francois Audet'; 'Dean Willis'; 'Jiri Kuthan'; 'SIP 
>> List'; 'Uzelac, Adam'
>> Subject: Re: [Sip] 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,
> 
> How would you do that?

There are a number of possibilities:

1) I could send an offerless invite, and await an offer from you. Then 
if it isn't something I can do myself I can recruit a transcoder to help.

2) I could send an invite with offer, and the callee could recruit the 
transcoder if needed.

3) I can send an invite with offer, and if you can't handle it, and 
don't have a transcoding alternative, you could send a 18x with an 
answer that refuses the media stream, but mentions the codecs you do 
support.

4) like 3, but use the sdp capability stuff to express the codecs that 
are supported in each direction.

5) I send invite with offer, you reject it with 488 because you can't 
support the codecs offered. The 488 indicates the codecs you do support. 
Then I recruit a transcoder and try the call again, offering somthing I 
expect you will be able to support.

	Thanks,
	Paul

> -d
> 
> 
>> 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-impor
>> tant-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