On Jan 15, 2008 8:20 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > The semantics of 'missed' are very context dependent. A simple > definition is 'no one answered the call', but in many systems that's not > likely. More likely is that it rolled over to voicemail, or to some > other user. If I'm in a sales office and a call comes to me, then it > falls back to the receptionist and is forwarded to the other sales > person across the aisle so they get the sale - is that a 'missed' call? > Depends on whether it's the company asking or just me...
I don't think that deployment issues like this should stop there being some kind of method for a UA to be informed of missed INVITE requests. While the "stuff" that goes on in the network is an implementation specific detail (and thus not specified), the semantics used by a UA to retrieve any missed calls (or other sip request perhaps) could be defined. We internally pass what is essentially a context (think histinfo) header around in requests within our network - while the requests often span 6+ servers to get to their destination, this context is still available until it leaves our network with pretty much identical demarcation points to P- headers [1] ... the point being exactly //how// we as a network keeps track of missed calls is up to us, but how our users UA's choose to retrieve the data we collect for them should not be. Currently, the user needs to log into a web interface to access that data. Yet it should be accessible to my phone! > The other problem is the well known one that it's hard to tell what > 'user' answered a call in SIP. It's not too hard to get the Contact > address, but that's not always easily mappable (certainly for a UA) to > an AOR, much less a human identity. Well, with GRUU it is possible for a period, at least to the issuer - depending on the allocation algorithm the registrar uses, it may be possible to always convert the GRUU to a sip instance. Again, this is more of a deployment problem than protocol one... ~ Theo 1 - It's slightly more complex than this as we have to add back when a call spirals to us again, but the point remains. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
