On Tue, 2009-12-08 at 23:42 +, Brez Borland wrote:
> Dale has a point. I was impressed watching talk dedicated to ipv6
> where major minds behind ipv6 development seemed to be straight
> ignorant, or least interested, in the notion of private network
> implementations such as NAT. their positio
On Mon, 2009-12-07 at 17:30 -0500, pvall...@csc.com wrote:
> When will that happen to SBCs..:)
Actually, SIP works quite well with SBCs, as long as the SBC does not
attempt to restrict what features of SIP are used. Unfortunately, many
service providers configure their SBCs not only to perform s
rs@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] REGISTER request, connection
>> termination
>>
>> Dale has a point. I was impressed watching talk dedicated to
>> ipv6 where major minds behind ipv6 development seemed to be
>> straight ignorant, or lea
bia.edu
> Subject: Re: [Sip-implementors] REGISTER request, connection
> termination
>
> Dale has a point. I was impressed watching talk dedicated to
> ipv6 where major minds behind ipv6 development seemed to be
> straight ignorant, or least interested, in the notion of
> p
Dale has a point. I was impressed watching talk dedicated to ipv6
where major minds behind ipv6 development seemed to be straight
ignorant, or least interested, in the notion of private network
implementations such as NAT. their position is that every device
should have a public IP. Which in my opi
On Mon, 2009-12-07 at 21:11 +0100, Iñaki Baz Castillo wrote:
> El Lunes, 7 de Diciembre de 2009, Dale Worley escribió:
> > On Wed, 2009-11-18 at 00:15 +0100, Iñaki Baz Castillo wrote:
> > > I still wake up every day asking myself how SIP protocol was born
> > > assuming there is no NAT... :(
> >
>
El Lunes, 7 de Diciembre de 2009, Dale Worley escribió:
> On Wed, 2009-11-18 at 00:15 +0100, Iñaki Baz Castillo wrote:
> > I still wake up every day asking myself how SIP protocol was born
> > assuming there is no NAT... :(
>
> How long have you been involved with the IETF? A lot of IETF people
>
On Wed, 2009-11-18 at 00:15 +0100, Iñaki Baz Castillo wrote:
> I still wake up every day asking myself how SIP protocol was born assuming
> there is no NAT... :(
How long have you been involved with the IETF? A lot of IETF people
hate NATs like the Pope hates Satan.
Dale
That is a shame indeed.. :(
On Tue, Nov 17, 2009 at 11:15 PM, Iñaki Baz Castillo wrote:
> El Miércoles, 18 de Noviembre de 2009, Brez Borland escribió:
>> Thank you all, it is clear to me now.
>>
>> Quick look at 5626. The new spec is big.
>
> Too big, too complex and too late IMHO.
> I still wak
El Miércoles, 18 de Noviembre de 2009, Brez Borland escribió:
> Thank you all, it is clear to me now.
>
> Quick look at 5626. The new spec is big.
Too big, too complex and too late IMHO.
I still wake up every day asking myself how SIP protocol was born assuming
there is no NAT... :(
--
Iñak
Thank you all, it is clear to me now.
Quick look at 5626. The new spec is big. But though made it easier on
me. At least we came up with the way to tackle these situations.
Regards,
Brez
On Tue, Nov 17, 2009 at 10:38 PM, Paul Kyzivat wrote:
>
>
> Brez Borland wrote:
>>
>> Hi all,
>>
>> Below
El Martes, 17 de Noviembre de 2009, Victor Pascual Avila escribió:
> On Tue, Nov 17, 2009 at 11:27 PM, Iñaki Baz Castillo wrote:
> > Read RFC 5256 "Managing Client-Initiated Connections" (previously
> > "sip-outboud draft"). It is the new way to handle those situations.
>
> * rfc5626
Thanks :)
Brez Borland wrote:
> Hi all,
>
> Below I assume using tcp transport for registrations.
>
> As I understand, while using a reliable transport for dialogs the
> connection between UAC and the next hop is active until the dialog is
> terminated by one party sending BYE and another party respondin
On Tue, Nov 17, 2009 at 11:27 PM, Iñaki Baz Castillo wrote:
> Read RFC 5256 "Managing Client-Initiated Connections" (previously "sip-outboud
> draft"). It is the new way to handle those situations.
* rfc5626
--
Victor Pascual Ávila
___
Sip-implementor
El Martes, 17 de Noviembre de 2009, Brez Borland escribió:
> Hi all,
>
> Below I assume using tcp transport for registrations.
>
> As I understand, while using a reliable transport for dialogs the
> connection between UAC and the next hop is active until the dialog is
> terminated by one party se
Hi all,
Below I assume using tcp transport for registrations.
As I understand, while using a reliable transport for dialogs the
connection between UAC and the next hop is active until the dialog is
terminated by one party sending BYE and another party responding back.
The connections on both side
16 matches
Mail list logo
