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

This is the wrong question to ask.

If an Enteprise does NOT want a service provider to "muck around" with
it's media, it will pick a service provider that does not, or use
4474 to ensure it doesn't happen.

I would expect that smaller Enteprises (SMB/SME) might be 
comfortable with a service provider that "adds value" by 
mucking around with its media. Presumably for NAT/Firewall traversal
reasons, willingness to be tapped into by the authorities, etc. 

> -----Original Message-----
> From: Elwell, John [mailto:[email protected]] 
> Sent: Wednesday, April 01, 2009 03:34
> To: Cullen Jennings; DRAGE, Keith (Keith)
> Cc: [email protected]; Audet, Francois (SC100:3055)
> Subject: RE: [Sip] francois' comments and why RFC4474 not 
> used in the field
> 
> I would like service providers to chip in here. Suppose I use 
> service providers to establish a call between two 
> enterprises. Enterprise A uses SP A for all external traffic, 
> and enterprise B uses SP B for all external traffic. We then 
> have a path:
> 
> 	Enterprise A -> SP A -> SP B -> Enterprise B.
> 
> What I would like to know is whether SP A and/or SP B would 
> have reason to change the SDP (also other aspects of the SIP 
> request, but just stick to SDP for now). If they need to 
> change it, then what drives this need to change the SDP: NAT 
> traversal, topology hiding, media steering, ....?
> 
> If SPs think they have no reason to change SDP in such 
> situations, then this part of the problem is solved. However, 
> I very much doubt that is the case.
> 
> John
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On 
> Behalf Of 
> > Cullen Jennings
> > Sent: 01 April 2009 02:24
> > To: DRAGE, Keith (Keith)
> > Cc: [email protected]; Francois Audet
> > Subject: Re: [Sip] francois' comments and why RFC4474 not 
> used in the 
> > field
> > 
> > 
> > In all of section 8, the only reason I find of why things 
> are changed 
> > is
> > 
> > "For media steering purposes, B2BUAs in intermediate 
> domains need to 
> > modify the IP address c-lines and the port in m-lines."
> > Even this one line leaves me confused about what 
> intermediate domains 
> > are in the deployment cases where this happens and if we 
> are talking 
> > about email style address or e.164 style addresses. What an 
> example is 
> > of a deployment where things like this happen and why the 
> middle (not 
> > the end domains) do the media steering. When I ask this of example 
> > people give me, if often turns out what is really wanted is 
> not media 
> > steering but the middle to be able to hide the fact that 
> they actually 
> > delivered the call to a third provider for PSTN termination.
> > 
> > Pretend 4474 does not even exist for a minute. I don't think it is 
> > unrealizable of me to ask what the problem is we are trying 
> to solve.
> > Saying 4474 is does not solve the problem may or may not be 
> true but 
> > we are unlikely to have a good conversation about about 
> what we should 
> > do until we understand what we are trying to accomplish.
> > 
> > 
> > On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote:
> > 
> > > Cullen wrote:
> > >
> > > > The thing I keep asking is can we make a list of reason why SDP 
> > > > and headers get changes and in what scenarios they do this. I 
> > > > think it will be hard to sort how to fix this without 
> being clear 
> > > > what needs to be fixed.
> > > >
> > >
> > > Isn't that the function of the text that was placed in 
> section 8 of
> > >
> > > 
> > 
> http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03
> > >
> > > If it is not, then what do you think is missing.
> > >
> > > regards
> > >
> > > Keith
> > >
> > > > -----Original Message-----
> > > > From: [email protected] 
> [mailto:[email protected]] On Behalf 
> > > > Of Cullen Jennings
> > > > Sent: Tuesday, March 31, 2009 11:32 PM
> > > > To: Jiri Kuthan
> > > > Cc: [email protected]; Francois Audet
> > > > Subject: Re: [Sip] francois' comments and why RFC4474 
> not used in 
> > > > the field
> > > >
> > > >
> > > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote:
> > > >
> > > > >
> > > > > I'm worried this is only a wishful thinking. While
> > > > perfectly logical,
> > > > > still even in such constrained setups some bizzar 
> ALGs do in my 
> > > > > experience appear in the middle, change SDP and make thus
> > > > the identity
> > > > > worthless.
> > > >
> > > > The thing I keep asking is can we make a list of reason why SDP 
> > > > and headers get changes and in what scenarios they do this. I 
> > > > think it will be hard to sort how to fix this without 
> being clear 
> > > > what needs to be fixed.
> > > >
> > > > For example, one of the things we might want to say is 
> something 
> > > > like:
> > > > the Phone is behind a NAT and connects to it's proxy / 
> registrar 
> > > > for its' domain. That proxy/b2bua whatever mucks with 
> IP/ports in 
> > > > the SDP for NAT traversal. Then we could ask if 4474 is 
> broken in 
> > > > this case or not and what might be a good way of solving the 
> > > > problem of having UAs behind NATs.
> > > >
> > > > Cullen <in my individual contributor role>
> > > >
> > > > _______________________________________________
> > > > 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
> > 
> 
_______________________________________________
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