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

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