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

Hans Erik,
 
Yes, except that SBC1 and SBC6 might not matter if the authentication
and verification services are collocated with them.
 
John


________________________________

	From: Hans Erik van Elburg [mailto:[email protected]] 
	Sent: 01 April 2009 15:23
	To: Elwell, John
	Cc: Cullen Jennings; DRAGE, Keith (Keith); [email protected];
Francois Audet
	Subject: Re: [Sip] francois' comments and why RFC4474 not used
in the field
	
	
	In that scenario you have probably passed 6 SBC's :-)
	
	    Enterprise A (SBC1) -> (SBC2) SP A (SBC3)->(SBC4) SP B
(SBC5)-> (SBC6) Enterprise B.
	
	/Hans Erik van Elburg
	
	
	
	On Wed, Apr 1, 2009 at 12:33 PM, Elwell, John
<[email protected]> wrote:
	

		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

_______________________________________________
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