< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Getting started


Hi All,

Thanks for all of your responses. You saved me a lot of time reading
source code just to figure out that it wouldn't work.  I will continue
to explore this, but will probably have to go with a different SIP
solution.

Best Regards,

Steve Hanka

-----Original Message-----
From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx] 
Sent: Monday, March 05, 2007 3:57 PM
To: Steve Hanka
Cc: Byron Campen; Jason Fischl; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Getting started

So what you're describing will take something that is fundamentally  
different from the stack
as it exists. You could build something that did what I think you're  
describing reusing some
of the stack's components (parser, scanner, some of the transport  
code). But it would be a
different thing when you were done and would become a separate  
project as opposed to
something that tried to live in the same library as the stack.

RjS

On Mar 5, 2007, at 3:55 PM, Steve Hanka wrote:

> Hi,
>
> The purpose of our stateless proxy is to route calls with load  
> balancing
> within a controlled cluster of servers and to ensure high-availability
> across a cluster of proxies without requiring the exchange of call  
> state
> information between them.
>
> Our application won't use DNS (we have our own routing database)  
> and we
> won't be maintaining transaction state.  We have internal  
> mechanisms for
> ensuring that we don't wind up with inadvertent forked calls; if a
> repeated INVITE, for example, is received on a different proxy our
> mechanisms ensure that it is sent to the same UAS as the original
> INVITE.
>
> If repro is dialog stateless and not transaction stateless it doesn't
> buy us anything.
>
> Best regards,
>
> Steve Hanka
>
>
> -----Original Message-----
> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> Sent: Monday, March 05, 2007 2:47 PM
> To: Jason Fischl
> Cc: Steve Hanka; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] Getting started
>
>       Just to be absolutely clear, when Jason says "stateless proxy
> based
> on resiprocate called repro", he means _dialog_-stateless, and not
> transaction-stateless.
>
> Best regards,
> Byron Campen
>
>> Here is a snippet of the discussion. You can find more of it using
>> google. I searched on:
>> site:list.sipfoundry.org resiprocate stateless proxy
>>
>> http://list.sipfoundry.org/archive/resiprocate-devel/msg00214.html
>>
>> The changes required in resiprocate would be substantial. I think  
>> that
>> as long as the api didn't require any major changes, the community
>> would be supportive.
>>
>> Are you sure that you need a stateless proxy? Why not use the
>> existing, stateless proxy based on resiprocate called repro. It  
>> should
>> do everything that you need and is high performance.
>>
>> It would be helpful to understand what your requirements are that
>> motivate using a stateless proxy.
>>
>> Jason
>>
>>
>>
>> On 3/5/07, Steve Hanka <steve.hanka@xxxxxxx> wrote:
>>> Regarding the flaws in stateless proxies that break the protocol:
>>>
>>> Does anyone know, in general, what these flaws are?  The RFCs
>>> specifically mention support for stateless proxies and I am
>>> curious as
>>> to what the problems are.
>>>
>>> Would anyone object if I investigated modifying the library to
>>> support
>>> them again?
>>>
>>> Best regards,
>>>
>>> Steve Hanka
>>>
>>>
>>> -----Original Message-----
>>> From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On
>>> Behalf
>>> Of Jason Fischl
>>> Sent: Monday, March 05, 2007 1:56 PM
>>> To: Byron Campen
>>> Cc: Steve Hanka; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>>> Subject: Re: [reSIProcate] Getting started
>>>
>>> The original reason that it was deprecated was for the reasons you
>>> listed. One of the consequences of deprecating it is that we  
>>> stripped
>>> out the support for stateless proxies from the transaction layer of
>>> resip. As a result, it is no longer possible to implement a  
>>> stateless
>>> proxy in resip without substantial changes to the library.
>>>
>>> Jason
>>>
>>>
>>> On 3/5/07, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
>>>>
>>>>  As far as I know, the stuff in deprecated is the only stateless-
>>> proxy
>>> code
>>>> we have. Anyone remember why specifically this was deprecated? I am
>>> under
>>>> the impression it was because stateless proxies in general had
>>> flaws
>>> that
>>>> broke the protocol in some situations, and not any specific flaw in
>>> the
>>>> code, but I could be wrong.
>>>>
>>>> Best regards,
>>>> Byron Campen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I am just getting started with reciprocate and am trying to get my
>>> mind
>>>> around the system.  For the last week I have been reading the
>>> source
>>> code,
>>>> looking at the test code and the API documentation, and so
>>> forth.  My
>>> goal
>>>> is to build a stateless proxy/message-relay server with some
>>> special
>>> routing
>>>> and message filtering capability for use in my employer's
>>> intelligent
>>>> network.
>>>>
>>>>
>>>>
>>>> I would like to find some sample code of a simple agent and a
>>> simple
>>> proxy.
>>>> I note that these pages are TBD in the documentation pages and that
>>> the
>>>> stateless proxy code in the source distribution has been
>>> deprecated.
>>> If
>>>> somebody will point me to such sample code, I will gladly write the
>>>> documentation pages once I figure out how the code works.
>>>>
>>>>
>>>>
>>>> Any suggestions?
>>>>
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>>
>>>>
>>>> Steve Hanka
>>>>
>>>> Steve.Hanka@xxxxxxx
>>>>
>>>> shanka@xxxxxxxx
>>>>
>>>>
>>>>
>>>>  ________________________________
>>>>
>>>>
>>>>  This message (including any attachments) may
>>>> contain confidential information intended
>>>> for a specific individual(s) and purpose,
>>>> and is protected by law. If you are not the
>>>> intended recipient, you should delete this
>>>> message.
>>>>
>>>>  Any disclosure, copying, or distribution of this
>>>> message, or the taking of any action based
>>>> on it, is strictly prohibited.
>>>> _______________________________________________
>>>> resiprocate-devel mailing list
>>>> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>
>>>> _______________________________________________
>>>> resiprocate-devel mailing list
>>>> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>> This message (including any attachments) may contain confidential
>>> information intended for a specific individual(s) and purpose, and
>>> is protected by law. If you are not the intended recipient, you
>>> should delete this message.
>>>
>>> Any disclosure, copying, or distribution of this message, or the
>>> taking of any action based on it, is strictly prohibited.
>>>
>>>
>
>
>
>
>
> This message (including any attachments) may contain confidential  
> information intended for a specific individual(s) and purpose, and  
> is protected by law. If you are not the intended recipient, you  
> should delete this message.
>
> Any disclosure, copying, or distribution of this message, or the  
> taking of any action based on it, is strictly prohibited.
>




 

This message (including any attachments) may contain confidential information 
intended for a specific individual(s) and purpose, and is protected by law. If 
you are not the intended recipient, you should delete this message. 

Any disclosure, copying, or distribution of this message, or the taking of any 
action based on it, is strictly prohibited.