From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Victor Pascual
Avila [victor.pascual.av...@gmail.com]
On Fri, Mar 19, 2010 at 1:37 PM, Iñaki Baz Castillo wrote:
(snip)
> Client side argum
Hi guys,
I am trying to wirte a gateway to transfer CDMA2000 call to VOIP call, did
anybody have any suggestion on tools or designs, or have any prototype to share?
Thanks,
Linda
> Date: Mon, 22 Mar 2010 18:34:07 +0100
> From: i...@aliax.net
> To: dwor...@avaya.com
> CC: sip-implementors@lis
2010/3/22 WORLEY, DALE R (DALE) :
> 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?
>
Pl find the below snippet in RFC 5628!
* It should remove any temporary GRUUs with a "callid" attribute
value different from that in the value of the "callid"
attribute of the , or with a "cseq" attribute with
value less than the value of the "first-cseq" attribut
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo [...@aliax.net]
One of the main problems I've found is the lack of a way to publish
permanente information via SIP. When
2010/3/22 WORLEY, DALE R (DALE) :
> A.2. Temporary GRUU
>
> This specification requires a registrar to create a new temporary
> GRUU on each registration refresh. If a registration is very long
> lived, this can quickly result in hundreds or even thousands of
> temporary GRUUs being crea
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat
[pkyzi...@cisco.com]
I thought this was discussed in the RFC. (But I'm too lazy to check
right now.)
__
Iñaki Baz Castillo wrote:
> But if the algorithm for constructing temp gruus would be known then
> it would become a vulnerability :(
Security by obscurity is never a great choice.
Crypto techniques can largely avoid the vulnerability.
I thought this was discussed in the RFC. (But I'm too laz
On Fri, Mar 19, 2010 at 1:37 PM, Iñaki Baz Castillo wrote:
(snip)
> Client side argument: A failing OPTIONS means that the server is
> unreachable so it doesn't make sense to send a BYE (taken such
> argument from RFC 3261 section 11):
>
> ---
> As is the case
