El Jueves, 11 de Junio de 2009, Paul Kyzivat escribió: > 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.
Ok, thanks for the explanation :) -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
