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

Setting up SRTP-only calls and using one or all of those techniques would
certainly be a way to learn how often intermediate transcoders are needed and
cannot be invoked.  Someone should try those techniques against some SIP
peers.  

I suspect even more interoperability issues would be encountered, but I am
only guessing.

-d


> -----Original Message-----
> From: Paul Kyzivat [mailto:[email protected]] 
> Sent: Saturday, April 04, 2009 2:00 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
> 
> 
> 
> 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