On Apr 1, 2009, at 4:33 AM, Elwell, John 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
I think this is exactly the right sort of question to be asking (and
we all agree they have reasons they are currently changing the SDP,
what we need to get at is why).
I think we also need to know about situations like
UA A -> SP A -> SP B -> UA B.
Enterprise A -> SP A -> SP B -> SP C -> Enterprise B.
And reasons SP B would change it. We also need to understand for each
use case if it is an E.164 number or email style name. We need to deal
with the cases where one of both of the ends is the PSTN not an
enterprise. We also need to understand the trust relationships between
the various entities. By that I mean things like "Enterprise B is
willing to trust SP C (who it pays) will not misroute it calls". Or
that UA A trust SP A not to give A's AOR to someone else.
Then we need to go through use case and figure out which requirements
derive the modification of key headers or bodies and which use cases
happen in real deployments and which ones are purely hypothetical.
They type of reasons for modification of headers/SDP that have been
raised in past include things like topology hiding, media steering,
nat traversal, and protocol repair.
Next we need to work on what the problem is. This includes things like
"I want to know who's phone I will be talking to if I answer this
ringing call so I can decide if I answer the call" or "I want to know
who's phone I am talking to at the other end so I can decide what I
might say", or "I want to be able to reject all calls at 2am that are
not from a phone that is listed in my personal address book". I'm not
proposing any of these are the right problem statement - I'm just
trying to give examples of they type of statement that if we agreed on
it would help us make progress.
We have proven over and ever again that without understanding what
problem we are trying to fix, we don't get very far. Saying that the
problem is "4474 does not work", does not help in the slightest. That
may or may not be true but it is not the problem - it's a statement
about if 4474 as a technology helps solve some unspecified problem or
not.
I have been advocating for years now that the discussion about if 4474
works for problem X or not is not going to get far without some
agreement on what the various values of X are.
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