Hadriel Kaplan wrote:
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul
>> Kyzivat
>>
>> IMO if I give you sip:[EMAIL PROTECTED], with or without user=phone,
>> then a call back to that URI MUST be via sip, and the 3263 rules say
>> that it MUST be routed to domain sp.com before making any decision about
>> how to reach something associated with the user part.
>
> Interesting. You said "if I give you... then a call *back* to that MUST be
> via sip". In what way do you mean "if I give you..."? Like in the From-URI
> of an outgoing request? Or out-of-band (e.g., on a business card)? Or both?
Sorry - I wasn't clear.
In this case what I had in mind (by referring to a "call back") was that
I gave it to you in a From-URI.
That's just one use case. A similar one would be if I gave it to you in
a vcard and you called me (not *back* in this case) using the URI from that.
>> If you are originating a call from a dial string, not a URI, then I
>> guess you can formulate the R-URI any way you want. But if the calling
>> party is supplying a URI (e.g. one it has saved from a prior received
>> call) then it should be used as-is.
>
> So how are we to tell which one it was, if you can formulate a dial string
> any which way? (I'm confused)
What I meant was: if you are a device with a URI that receives digits
and uses them to construct a URI, rather than receiving a URI, then you
can create the URI any way you want. We don't have a lot of rules about it.
For instance, you could just take the digits, slap "sip:" on the front,
and "@domain;user=dialstring" on the back, and it would be very
explicit. But of course almost nobody does that.
Or you could do the above but leave the user=dialstring off, on the
agreement that it will be understood as a dialstring.
Or you could use some dial plan info local to the UAC to translate the
dial string into an E.164 number, and then put that into a sip: or tel: URI.
How the UA decides if it is getting a dial string or a URI is up to it,
and is strongly a function of its UI. In many cases this will be quite
obvious. (E.g. If all it has is a number pad.) If the device is capable
of full keyboard input, then it may always expect full URIs, or it may
take either and distinguish based on the syntax of the text entered.
>> If you want some server on the originating end to do something for the
>> outbound call, then you should put a Route header in the request
>> identifying the server.
>
> And I wish that would work, but in many cases it won't.
AFAIK we are in the business of determining the valid ways of doing
things. If implementations choose to do otherwise all we can do is keep
encouraging.
> For some of those cases I think it's because of bad equipment, and hopefully
> not a permanent problem. But the From-URI you end up getting has a host-part
> that is of the previous or local domain, instead of the real originating
> domain, and thus the Req/To-URI you end up generating later will likewise be
> the local or next-domain. If we could get wider vendor support for Tel-URIs
> (and Route headers), this problem will go away eventually... I hope.
The problem with trying to make up for the inadequacies of the neighbors
is - how do you know which ones do it right and which do it wrong?
I guess you SBC guys can keep getting the business to try to solve that
problem. But it really means a bunch of configuration about the
idiosyncrasies of all the peers. That only works when there are a
limited number of them.
Paul
> -hadriel
> _______________________________________________
> 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
