> -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
Thank You very much Guys!
On Fri, Feb 27, 2009 at 5:26 AM, Brett Tate wrote:
> The request is malformed. The receiver can basically handle it however it
> desires.
>
> Returning "400 Fix Contact Expires Parameter" would be ideal.
> Unfortunately returning failure responses to REGISTER often ca
Hi,
We want to add support for parsing messages defined as per following
requirement from 3GPP TS 23.003 specification.
"
The public service identity shall take the form of either a SIP URI (see
IETF RFC 3261 [26]) or a Tel URI (see IETF RFC 3966 [45]). A public service
identity identifies a
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
Oops, that was the wrong key... Too many mail clients.
I meant to say, I believe some such document already is present, although it
is more of a
Table Of Contents over SIP related documents, and not an Implementation
Guide.
We are currently 'trying' to make a SIP software device, which may yet
> Why not the following?:
>
> 200 with default registrar Expires value (probably 3600)?
If you mean local default, that is the implied interpretation of "2) Return 200
with Contact as though expires parameter not received".
If you are referring to the following SHOULD, that is obviously OK. :
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
2009/2/27 Brett Tate :
> The request is malformed. The receiver can basically handle it however it
> desires.
>
> Returning "400 Fix Contact Expires Parameter" would be ideal. Unfortunately
> returning failure responses to REGISTER often causes frequent REGISTERs with
> the same issue until fi
The request is malformed. The receiver can basically handle it however it
desires.
Returning "400 Fix Contact Expires Parameter" would be ideal. Unfortunately
returning failure responses to REGISTER often causes frequent REGISTERs with
the same issue until finally resolved (by reconfiguration
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
Hi Ben,
On Fri, Feb 27, 2009 at 8:51 AM, BONNAERENS Ben
wrote:
>> On the same note, it's shocking how many devices bail out
>> after receiving a 503 and just give up. Please,
>> implementers: 503 does not mean "never try registering again".
>
> Let me refine this statement a bit:
> 503 also do
Hi Theo,
> On the same note, it's shocking how many devices bail out
> after receiving a 503 and just give up. Please,
> implementers: 503 does not mean "never try registering again".
Let me refine this statement a bit:
503 also does not mean "immediately retry to register"
One should respect
22 matches
Mail list logo
