Dale Worley wrote:
> On Mon, 2009-03-30 at 12:35 +0100, Stephen Paterson wrote:
>> I'm currently implementing RFC 3265 as an abstract layer upon which our
>> customers can build their own event packages and I'm trying to determine
>> exactly what information their applications will need in order
On Mon, 2009-03-30 at 12:35 +0100, Stephen Paterson wrote:
> I'm currently implementing RFC 3265 as an abstract layer upon which our
> customers can build their own event packages and I'm trying to determine
> exactly what information their applications will need in order to
> support any possible
+1
Michael Procter wrote:
> Scott Lawrence wrote:
>> On Thu, 2009-04-02 at 10:03 +0100, Stephen Paterson wrote:
>>> Hi all,
>>> Thanks for your replies. Lots of answers saying I'll only get a single
>>> 200. Sorry, bit of a slip on my part there! Ignore the '200/' and you'll
>>> get my meaning.
>>
Scott Lawrence wrote:
> On Thu, 2009-04-02 at 10:03 +0100, Stephen Paterson wrote:
> > Hi all,
> > Thanks for your replies. Lots of answers saying I'll only get a single
> > 200. Sorry, bit of a slip on my part there! Ignore the '200/' and you'll
> > get my meaning.
> > Anyway, just to finish off,
9 15:28
To: Stephen Paterson
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Forked SUBSCRIBE responses
On Thu, 2009-04-02 at 10:03 +0100, Stephen Paterson wrote:
> Hi all,
> Thanks for your replies. Lots of answers saying I'll only get a single
> 200. Sorry,
On Thu, 2009-04-02 at 10:03 +0100, Stephen Paterson wrote:
> Hi all,
> Thanks for your replies. Lots of answers saying I'll only get a single
> 200. Sorry, bit of a slip on my part there! Ignore the '200/' and you'll
> get my meaning.
> Anyway, just to finish off, I'll be adding a flag so that the
Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: 02 April 2009 10:56
To: Stephen Paterson
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Forked SUBSCRIBE responses
2009/4/2 Stephen Paterson :
> Anyway, just to finish off, I'll be adding a
Iñaki Baz Castillo wrote:
> 2009/4/2 Stephen Paterson :
>
> > Anyway, just to finish off, I'll be adding a flag so that the user can
> > say whether they want to accept multiple dialogs or not.
>
> Not possible. A proxy doing forking for a SUBSCRIBE (non-INVITE
> transaction) will just accept the f
2009/4/2 Stephen Paterson :
> Anyway, just to finish off, I'll be adding a flag so that the user can
> say whether they want to accept multiple dialogs or not.
Not possible. A proxy doing forking for a SUBSCRIBE (non-INVITE
transaction) will just accept the first 200 Ok and drop the rest. So
the
Hi all,
Thanks for your replies. Lots of answers saying I'll only get a single
200. Sorry, bit of a slip on my part there! Ignore the '200/' and you'll
get my meaning.
Anyway, just to finish off, I'll be adding a flag so that the user can
say whether they want to accept multiple dialogs or not. The
On Mon, 2009-03-30 at 12:35 +0100, Stephen Paterson wrote:
> Hi all,
>
> I'm currently implementing RFC 3265 as an abstract layer upon which our
> customers can build their own event packages and I'm trying to determine
> exactly what information their applications will need in order to
> support
El Lunes 30 Marzo 2009, Stephen Paterson escribió:
> E.g.. a UA receives N 200 responses from a single subscribe
This is not possible. When a proxy (the node which does forking) receives a
200 it will not allow a next 200 from other branch.
--
Iñaki Baz Castillo
__
t; Cheers
> Steve
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Stephen Paterson
> Sent: 30 March 2009 12:35
> To: sip-implementors@lists.cs.columbia.edu
>
t: 30 March 2009 12:35
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Forked SUBSCRIBE responses
Hi all,
I'm currently implementing RFC 3265 as an abstract layer upon which our
customers can build their own event packages and I'm trying to determine
exactly what in
Hi all,
I'm currently implementing RFC 3265 as an abstract layer upon which our
customers can build their own event packages and I'm trying to determine
exactly what information their applications will need in order to
support any possible such package.
Small question, if a given package allows mu
15 matches
Mail list logo
