Thank you so much for the detailed explanation.
On Sat, Mar 20, 2010 at 1:41 AM, WORLEY, DALE R (DALE) wrote:
>
> From: sip-implementors-boun...@lists.cs.columbia.edu [
> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Premalatha
> Kuppan [pre
LinkedIn
Anjan Naik requested to add you as a connection on LinkedIn:
--
Priyank,
I'd like to add you to my professional network on LinkedIn.
- Anjan
Accept invitation from Anjan Naik
http://www.linkedin.com/e/cFM0GAd-yBCwaJGWsQs1GGTyK-p78Ke3D
It's amazing that such a fundamental session configuration topic is not really
well specified (explicitly, detailed, unambiguous) in RFCs 3261 & 3264. Just
wondering ...
-Albrecht
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun
2010/3/21 Paul Kyzivat :
> Iñaki,
>
> This is probably far from obvious.
>
> The reason for creating new ones was because for anonymization purposes you
> probably don't want to keep using the same one. It would have been better to
> have an explicit mechanism to request when you want a new one, bu
2010/3/21 Saúl Ibarra :
>> Unfortunatelly PUBLISH requires a "Expires" header and its value
>> cannot be infinite (can it be??). Of course I don't want temporal
>> storage of the buddies, but permanent. Is there any way to publish
>> permanent information with PUBLISH?
>>
>
> Trying to change the w
Iñaki,
This is probably far from obvious.
The reason for creating new ones was because for anonymization purposes
you probably don't want to keep using the same one. It would have been
better to have an explicit mechanism to request when you want a new one,
but that didn't fit into the model w
Hi Iñaki,
On Sun, Mar 21, 2010 at 1:59 PM, Iñaki Baz Castillo wrote:
> Hi, I'm starting a new specifications for SIP presence, totally from
> scratch. I won't reuse any of the current painful specifications
> (presence model, XCAP, resource-lists, pres-rules, resource-lists...),
> neither HTTP pr
2010/3/21 Iñaki Baz Castillo :
> Hi, after reading the RFC 5627 I don't understand why the registrar
> can create a new temp-gruu URI for each registration refresh.
> If it does so, the registrar would end with a database full of temp-gruu
> URI's.
>
> From the point of view of a registrar impleme
Hi, after reading the RFC 5627 I don't understand why the registrar
can create a new temp-gruu URI for each registration refresh.
If it does so, the registrar would end with a database full of temp-gruu URI's.
From the point of view of a registrar implementing GRUU, is it posible
to mantain an uni
2010/3/21 Iñaki Baz Castillo :
> If not, which would be the best approach?:
>
> b) Allowing "Expires: infinite" in PUBLISH. This is hard as involves a
> SIP basic grammar modification.
Also, the UAC could send the PUBLISH without "Expire" header, but the
200 response from the server requires to ha
2010/3/21 Olle E. Johansson :
> Fully agree. Why I keep being persistent here is that too many applications
> assume that 183 means ringing. They just don't understand the importance of
> the
> state change of the call in the network - "the user will hear the ringing".
> Audio
> is not the only w
Hi, I'm starting a new specifications for SIP presence, totally from
scratch. I won't reuse any of the current painful specifications
(presence model, XCAP, resource-lists, pres-rules, resource-lists...),
neither HTTP protocol (just SIP for all).
For example, a buddy (a SIP contact) is a XML docum
20 mar 2010 kl. 19.45 skrev Pranab Bohra:
> In my opinion, the decision on whether to respond with 183 or 180,
> with or without SDP and other things related to early media should be
> taken on case-by-case basis.
> In case of analog termination, as in the present case, ring-tone or
> progress in
13 matches
Mail list logo
