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

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Hans Erik van Elburg
> Sent: Wednesday, April 01, 2009 7:23 AM
> To: Elwell, John
> Cc: Cullen Jennings; [e-mail]; Francois Audet; DRAGE,Keith (Keith)
> 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.

And I doubt that every VoIP SP will be meshed with every other VoIP SP.  So in
many situations there will be a transit SP or two along the path.  The PSTN
has transit service providers (my local phone company is not directly
connected with the phone company in Syria or India), and the Internet has
transit service providers (some little ISP in Wyoming is not directly
connected with a little ISP in Switzerland).

-d


> /Hans Erik van Elburg
> 
> 
> 
> On Wed, Apr 1, 2009 at 12:33 PM, Elwell, John 
> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
> 	> Behalf Of Cullen Jennings
> 	
> 	> Sent: 01 April 2009 02:24
> 	> To: DRAGE, Keith (Keith)
> 	> Cc: [e-mail]; 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: [e-mail] 
> [mailto:[e-mail]] On
> 	> > > Behalf Of Cullen Jennings
> 	> > > Sent: Tuesday, March 31, 2009 11:32 PM
> 	> > > To: Jiri Kuthan
> 	> > > Cc: [e-mail]; 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
> 	> > > [e-mail] for questions on 
> current sip
> 	> > > Use [e-mail] 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 [e-mail] for questions on 
> current sip
> 	> Use [e-mail] 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 [e-mail] for questions on 
> current sip
> 	Use [e-mail] for new developments on the 
> application of sip
> 	
> 
> 
>