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

John,

In my experience, service providers (such as the one I work for)
sometimes change the SDP in situations like this, and sometimes don't.
It depends on whether the service providers' VoIP infrastructure is in
the public Internet address space, or a private address space (e.g.,
MPLS/BGP -based VPN).  Use of the latter configuration requires NAT and
SIP ALG functionality "at the edge".  In the diagram below there is an
"edge" everywhere you draw an arrow.  Typically the devices that
implement the NAT and SIP ALG functions do other things, like topology
hiding and steering the media to a device that will then monitor
("police") its arrival rate.

Alternatively, if the SP's infrastructure is in the public address
space, you typically don't see NAT / SIP ALG or topology hiding or media
steering.  You may (often do) still see "border devices" doing things
like traffic aggregation and policy based routing.

In either case, it's not uncommon that the border elements modify other
aspects of the SIP signaling for reasons of interoperability.  For
example it's sometimes [believed to be] necessary to modify response
codes due to differing implementations - e.g., to break an
infinite-retry loop.

tim
 

> 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