On Thu, 26 Feb 2009, Daniel-Constantin Mierla wrote:
> Running an IP-based service without a good managed DNS server does not
> sound good for me. It is not expensive to get a proper one.
Sure, but small business can't become their own "*small*" SIP provider
because managing DNS for SIP is not
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
> Castillo
> Sent: Friday, February 27, 2009 4:59 AM
>
> >> We have at least two cases now where an update to the RFC added
> >> im
27 feb 2009 kl. 15.32 skrev Iñaki Baz Castillo:
> 2009/2/27 Olle E. Johansson :
>> I think what you're saying here is really the core. We need to expand
>> the IETF group and be able to give more feedback. And be helpful to
>> new developers. This mailing list is an essential tool.
>
> Sincerelly
2009/2/27 Olle E. Johansson :
> I think what you're saying here is really the core. We need to expand
> the IETF group and be able to give more feedback. And be helpful to
> new developers. This mailing list is an essential tool.
Sincerelly I don't expect that IETF-SIP is a good place for
implemen
27 feb 2009 kl. 15.00 skrev Stephane van Hardeveld:
> It's almost impossible to go through all the SIP and SIP related
> RFCs and get a clear picture. Before you implement - ask on the
> mailing list. Even though I've read documents to my eye bleed
> and hacked SIP code for many years, I still le
bly bother you all a lot...
Stephane
- Original Message -
From: "Stephane van Hardeveld"
To: "Stephane van Hardeveld"
Cc: "SIP Mailing list Implementors"
Sent: Friday, February 27, 2009 3:00 PM
Subject: Re: [Sip-implementors] [Kamailio-Users] Secure VoIP
&g
It's almost impossible to go through all the SIP and SIP related
RFCs and get a clear picture. Before you implement - ask on the
mailing list. Even though I've read documents to my eye bleed
and hacked SIP code for many years, I still learn new things on this
list (and find new bugs in the software
27 feb 2009 kl. 08.49 skrev Theo Zourzouvillys:
> On Thu, Feb 26, 2009 at 2:57 PM, Olle E. Johansson
> wrote:
>>
>>> IETF guys should visit our planet someday.
>
> Agreed. There are some people - me included - who live on both
> planets. but as time goes by, those people are becoming less and
Hi Everyone,
After reading the full chain of mails, I who is currently implementing RFC
3263 feels bit confused. I am not facing any major problems implementing it.
Can i request to give me some points which are dicey and I need to take care
of them.
cheers
sarvpriya
On Fri, Feb 27, 2009 at 4
26 feb 2009 kl. 18.27 skrev Daniel-Constantin Mierla:
> On 02/26/2009 07:08 PM, Iñaki Baz Castillo wrote:
>> 2009/2/26 Daniel-Constantin Mierla :
>>
>>> However, being out there so many phones without such support, it is
>>> practically unusable since service providers won't deploy
>>> differen
26 feb 2009 kl. 18.09 skrev Bogdan-Andrei Iancu:
> See here some hard numbers (thanks to Robert):
>https://www.sipit.net/SIPit23_Summary
>
>
>
> For DNS we had support for:
> Full RFC3263: 65% (continuing to climb)
> SRV only: 15%
> A records only : 13%
2009/2/27 Theo Zourzouvillys :
> On Fri, Feb 27, 2009 at 9:50 AM, Iñaki Baz Castillo wrote:
>> - In case the SIP URI explicitely defines a port then only those SRV
>> records using that port must be selectable.
>
> Wrong! If there is a port, you don't do an SRV lookup.
>
>> - In case ";transport=
Iñaki Baz Castillo wrote:
> 2009/2/27 Theo Zourzouvillys :
>
>>> IMHO RFC 3263 complexity doesn't help too much.
>>>
>> I don't see any real complexity in RFC 3263 for a well engineered
>> stack. What do you see as being complex about it?
>>
>
> - In case the SIP URI explicitely def
On Fri, Feb 27, 2009 at 9:50 AM, Iñaki Baz Castillo wrote:
> - In case the SIP URI explicitely defines a port then only those SRV
> records using that port must be selectable.
Wrong! If there is a port, you don't do an SRV lookup.
> - In case ";transport=XXX" parameter appears in the SIP URI on
>> We have at least two cases now where an update to the RFC added
>> important MUSTs:
>>
>> - Tel uri - phone-context is now required, which affects all SIP
>> devices using SIP uri with user=phone
>> regardless if they use a Tel: URI.
Sincerelly I can't understand the usage/requeriment of "us
2009/2/27 Theo Zourzouvillys :
>> IMHO RFC 3263 complexity doesn't help too much.
>
> I don't see any real complexity in RFC 3263 for a well engineered
> stack. What do you see as being complex about it?
- In case the SIP URI explicitely defines a port then only those SRV
records using that port
On Thu, Feb 26, 2009 at 2:57 PM, Olle E. Johansson wrote:
>
>> IETF guys should visit our planet someday.
Agreed. There are some people - me included - who live on both
planets. but as time goes by, those people are becoming less and less.
This is mostly, it would seem, due to many of the peopl
On Thu, Feb 26, 2009 at 3:26 PM, Iñaki Baz Castillo wrote:
> RFC 3263 (Locating SIP Servers) is really complex, NAPTR is really
> complex, and it's not needed in 99% of current SIP deployments, so
> vendors don't implement it. If a SIP provider whises to use NAPTR
> records then all its clients s
On Thu, Feb 26, 2009 at 5:08 PM, Iñaki Baz Castillo wrote:
>> However, being out there so many phones without such support, it is
>> practically unusable since service providers won't deploy different server
>> solutions for each group of devices, so they stick to one size fits all and
>> that is
On 02/26/2009 09:44 PM, Aymeric Moizard wrote:
>
>> 2009/2/26 Daniel-Constantin Mierla :
>
>> True, what I mean is that SIP providers don't offer a NAPTR record for
>> their service since most clients don't implement it.
>
> But NAPTR request on windows are a pain.
then indeed, this is a solid reas
On 02/26/2009 07:30 PM, Iñaki Baz Castillo wrote:
> 2009/2/26 Daniel-Constantin Mierla :
>
>>> Devices don't implement it, so service providers don't implement it,
>>> so devices don't implement it, so... XD
>>>
>>>
>> I think the sip server implementations are pretty good here. Besides
2009/2/26 Bogdan-Andrei Iancu :
>> IMHO RFC 3263 complexity doesn't help too much.
>>
>
> I wouldn't say so. I personally implemented this RFC and it is very helpful
> if you understand it and if you are able to take advantage of all its
> functionalities (discovery, failover, balancing, etc)
>
>
2009/2/26 Daniel-Constantin Mierla :
>> Devices don't implement it, so service providers don't implement it,
>> so devices don't implement it, so... XD
>>
>
> I think the sip server implementations are pretty good here. Besides that,
> for client interaction it is required only DNS server configur
Iñaki Baz Castillo wrote:
> 2009/2/26 Daniel-Constantin Mierla :
>
>> However, being out there so many phones without such support, it is
>> practically unusable since service providers won't deploy different server
>> solutions for each group of devices, so they stick to one size fits all and
On 02/26/2009 07:08 PM, Iñaki Baz Castillo wrote:
> 2009/2/26 Daniel-Constantin Mierla :
>
>> However, being out there so many phones without such support, it is
>> practically unusable since service providers won't deploy different server
>> solutions for each group of devices, so they stick to
2009/2/26 Bogdan-Andrei Iancu :
> See here some hard numbers (thanks to Robert):
> https://www.sipit.net/SIPit23_Summary
>
>
>
> For DNS we had support for:
> Full RFC3263 : 65% (continuing to climb)
> SRV only : 15%
> A records only : 13%
> no DNS support
See here some hard numbers (thanks to Robert):
https://www.sipit.net/SIPit23_Summary
For DNS we had support for:
Full RFC3263 : 65% (continuing to climb)
SRV only : 15%
A records only : 13%
no DNS support : 7%
So 65% with NAPTR and 80% with S
2009/2/26 Daniel-Constantin Mierla :
> However, being out there so many phones without such support, it is
> practically unusable since service providers won't deploy different server
> solutions for each group of devices, so they stick to one size fits all and
> that is not DNS for now.
Devices d
On 02/26/2009 06:40 PM, Klaus Darilion wrote:
> Iñaki Baz Castillo wrote:
>
>> 2009/2/26 Olle E. Johansson :
>>
>>> This is a problem I realize at every SIPit. The implementations are far away
>>> from the IETF world. And the gap doesn't seem to close.
>>>
>>> Basic stuff like DNS is not un
2009/2/26 Klaus Darilion :
>> RFC 3263 (Locating SIP Servers) is really complex, NAPTR is really
>> complex, and it's not needed in 99% of current SIP deployments, so
>> vendors don't implement it. If a SIP provider whises to use NAPTR
>> records then all its clients should implement it in their SI
Iñaki Baz Castillo wrote:
> 2009/2/26 Olle E. Johansson :
>> This is a problem I realize at every SIPit. The implementations are far away
>> from the IETF world. And the gap doesn't seem to close.
>>
>> Basic stuff like DNS is not understood or used by many SIPit attendees so
>> even trying to ment
2009/2/26 Olle E. Johansson :
> This is a problem I realize at every SIPit. The implementations are far away
> from the IETF world. And the gap doesn't seem to close.
>
> Basic stuff like DNS is not understood or used by many SIPit attendees so
> even trying to mention NAPTR is too complex, and it'
26 feb 2009 kl. 15.20 skrev Iñaki Baz Castillo:
> 2009/2/26 Johansson Olle E :
>> " This document provides clarifications and guidelines concerning the
>> use of the SIPS URI scheme in the Session Initiation Protocol (SIP).
>> It also makes normative changes to SIP."
>> "1. Introduction
>> The me
33 matches
Mail list logo
