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
