Cullen Jennings wrote:
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."
Hi Cullen,
really the trouble is that any list of SDP-mangling scenarios is too
short to capture it. as an example, I think ALGs are "illegitimate"
in that they do provide only an illusion of security and break
things at the same time. Still they do appear withouth what I would
call a "good reason" and break things.
Therefore I would prefer actually something more end-2-end-ish, in that
it is robust in the ends and makes minimum assumptions about network
being nice. That's not an argument for encouraging evil things in the
network. That's just an argument for being able to deal with them.
Does this appear silly? I'm somehow worried I haven't made my point
quite well.
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.
My viewpoint is that the case you mention is another element on
a list of scenarios, which we may or may not understand, may or may
not be reasonable, but very likely will appear in the field and
break SDP's integrity.
For my own purposes I would be happy if IP+port+codec were not protected
but I guess that others would fail elsewhere.
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.
I wish the callee to know caller's identity. (May or may not be what others
are interested in.) The notion of identity is a bit vague -- I'm not
refering
DNA sort of identity. For mostof the purposes I know a good-enough notion
identity accomodates traceability and change-of-change. Traceability
gives me the ability to call back and fingerpoint ath the caller.
Cost-of-change
is prohibitive for those who want to make identity worthless by changing
it oon a grand scale. Having DNS in URI IMO accomodates the cost-of-change
requirement, as long as we have certainity caller cannot easily use
someone else's DNS. A non-sip example to me is car license plates.
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.
I think it does solve my identity problem, but breaks because of the SDP
thing.
-jiri
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
