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

Reply via email to