Re: francois' comments and why RFC4474 not used in the field
Hans Erik van Elburg <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
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