Hadriel Kaplan wrote:
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>>
>> 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.
>
> Ah, ok. The only issue then is that when a UAC generates a request, it's not
> really clear how it should know when it wants things back *only* via SIP, or
> when it doesn't care. For example, if you make a phone call, why would your
> UAC use a From-URI of TEL?
>
> It would (typically) be your registered AoR, and sip:[EMAIL PROTECTED] And
> yet I doubt very much that most phones, or their users, really care whether
> people calling them *back* go through the PSTN or not to reach their SIP
> phone. I bet most of them have no idea they're even *using* a SIP phone.
Yes, this is definitely a policy issue. And for many phones it really
won't matter. In that case I think they would be best to use tel:.
(Except of course that may introduce interop problems with devices that
don't support tel. But those will be fixed by SBCs :-)
It starts to matter when the device does more than audio.
>>>> 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.
>
> Absolutely. But pragmatism has its place too. (I'm not saying this is one of
> those times though)
>
>
>> 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?
>
> With some things it's part of the peering agreement (e.g., a "profile"), with
> some things it's based on device-specific config or vendor-profiles. But for
> some things it's a lowest-common-denominator: change it to what works with
> every device.
>
>
>> 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.
>
> Yup, and why I'm trying to get things to stop needing to be "fixed". It's
> not core to an SBC's value prop, and not a good long-term strategy for such.
I'm really glad to hear that. And even though you are a marketing guy, I
believe you.
Paul
_______________________________________________
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
