Iñaki Baz Castillo wrote:
> El Miércoles, 10 de Junio de 2009, Paul Kyzivat escribió:
>
>> Actually, *in theory*, you can put Accept-Language:es into your INVITE,
>> and then the text messages in the response ought to be written in Spanish.
>>
>> (And of course everybody's SIP implementation does that. :-)
>
> Yes, I was to say the same XD
>
>
>
>> Practically speaking, if you want the caller to display some indication
>> with a specific semantic then you do need some signaling that coveys
>> that semantic. The 182, ignoring the reason phrase, comes *close* -
>> close enough that IMO it would be reasonable for a UA to display some
>> message that the user would reasonably interpret as call waiting.
>
> Ok, I like this, more than what you suggest now:
>
>
>> To get more specific than that, I have, for quite some time, been
>> promoting the concept of using Alert-Info with a URN, and defining URNs
>> with specific semantics. Having one with a "call waiting" semantic would
>> be quite reasonable. Alert-Info in a response is already defined, so
>> this is not an abuse. The main problem preventing use of Alert-Info with
>> URIs has, IMO, been one of trust - you don't know whether you are going
>> to get something offensive or dangerous. Using URNs with agreed upon
>> semantics eliminates that issue.
>
> Do you mean that the UAC receives a 1XX with Alert-Info header containing an
> URN for "call waiting" so the UAC would contact the URN URI and so on?
Yes.
> Sincerelly I don't like this idea, why should it contact a remote server just
> to understand the call-waiting concept?
The point is URN, not URL. The URN is a *name*, not a *location*, so you
don't contact any remote server. You either understand the name, or you
don't. You are potentially able to understand it because there is a
registry of URNs (in IANA) that points to a definition of what it means.
But you will have to teach your software the URNs you want it to understand.
So, it is really just a different extension mechanism. In this case it
would be used as an extension mechanism for alerts.
> Also, being realistic, most of the phones ignore Alert-Info header, or at
> least, ignore contacting its URI. Am I wrong?
No, you are right, I think. This is just a potential way forward for
functionality of this sort, where there might be lots of different kinds
of alerts that are useful, but in an environment where I don't want to
fetch some URL, especially an unknown one that I might not trust.
Because alerts are advisory, its probably fine if a recipient that
doesn't understand one just ignores it.
Alerts defined by URNs could have all sorts of different degrees of
definition:
- It could denote a particular tone or audio clip
- It could denote a particular piece of music but not its rendition
- It could be some text that is intended to be localized for the
receiver
- It could simply be a concept, with the rendition left open for
the implementation (e.g. EMERGENCY)
- ...
I believe this approach is being adopted by 3gpp for some things, but I
don't have the details.
Of course if you just want something you can use today, this won't help.
It is simply a possible direction forward.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
