Skip to main content

SIP Proxy service - conflict with auto-dialogs in SIP RA 1.2

2 replies [Last post]
ivelin
Offline
Joined: 2003-07-13
Points: 0

seems to me that a clean way to resolve this type of conflicts is for the proxy service to use its own SIP RA instance listening on a dedicated port.

Services interested in auto-dialogs would most likely act as end-points of some sort and would therefore be a forwarding target of the proxy.

So all external SIP requests would go to the SIP RA of the proxy (port 5060) and it will use some local configuration policy to forward to the port of the SIP RA for end points (e.g. port 5070).

This is going back to the earlier discussion of leveraging the recent update to JSIP 1.2, which allows multiple stacks with individual ports sharing the same jsip implementation. I find this a clean and simple solution.

>
> One more issue remains - sip ra 1.2, automatic dialog
> creation and proxy?
> How does this relate to each other? I mean if we have
> service that creates dialog proxy wont receive event
> since it will be fired as "in dialog". This happens
> because RA determines whaether in dialog event can be
> received. However at that moment it doesnt have any
> knowledge if it will be processed. If its not, dialog
> could be created (if it is INVITE request) anyway -
> possible solution is to make RA check if that INVITE
> was processed successfuly, if not it should fire
> again that event, as not in dialog event.
>
> Secodn solution would be to change slitghtly design
> and make RA fire events when they are expected, I
> mean if RA detects that both 1.1 and 1.2 are expected
> it will fire both , but this can lead to some
> ambiguity.
>
> Any comments?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mranga
Offline
Joined: 2003-06-06
Points: 0

> seems to me that a clean way to resolve this type of
> conflicts is for the proxy service to use its own SIP
> RA instance listening on a dedicated port.
>
> Services interested in auto-dialogs would most likely
> act as end-points of some sort and would therefore be
> a forwarding target of the proxy.
>
> So all external SIP requests would go to the SIP RA
> of the proxy (port 5060) and it will use some local
> configuration policy to forward to the port of the
> SIP RA for end points (e.g. port 5070).
>
> This is going back to the earlier discussion of
> leveraging the recent update to JSIP 1.2, which
> allows multiple stacks with individual ports sharing
> the same jsip implementation. I find this a clean and
> simple solution.

I agree that this would be a good way to resolve the problem. One shoe does not fit all. Some services like IVR are best done using a dialog stateful application. Other services like proxy are best constructed as stateless (or call stateful ) applications.

I think the JSIP RA should include the ability to support stateless operation. If necessary define a Null activity bound to a name which is used to fire events on for stateless messages.

>
> >
> > One more issue remains - sip ra 1.2, automatic
> dialog
> > creation and proxy?
> > How does this relate to each other? I mean if we
> have
> > service that creates dialog proxy wont receive
> event
> > since it will be fired as "in dialog". This
> happens
> > because RA determines whaether in dialog event can
> be
> > received. However at that moment it doesnt have
> any
> > knowledge if it will be processed. If its not,
> dialog
> > could be created (if it is INVITE request) anyway
> -
> > possible solution is to make RA check if that
> INVITE
> > was processed successfuly, if not it should fire
> > again that event, as not in dialog event.
> >
> > Secodn solution would be to change slitghtly
> design
> > and make RA fire events when they are expected, I
> > mean if RA detects that both 1.1 and 1.2 are
> expected
> > it will fire both , but this can lead to some
> > ambiguity.
> >
> > Any comments?

ivelin
Offline
Joined: 2003-07-13
Points: 0

>
> I think the JSIP RA should include the ability to
> support stateless operation. If necessary define a
> Null activity bound to a name which is used to fire
> events on for stateless messages.
>

Sounds like an idea. How about a configurable option for the SIP RA, which specifies the name of the activity where all SIP messages will be delivered statelessly. If the option is omitted, the SIP RA will not fire such events.

Services interested in the stateless SIP messages, such as the Statelss Proxy service, will attach to the named activity specified in the RA config option.

The only concern with this aproach is the fact that there is no standard way for an RA to create a named activity.

An alternative approach would be to use a custom event type - StatelessSipActivity, which can be used by a smart JSLEE 1.1 RA to detect services interested in stateless events. When the RA is installed it will passively listen for services to be deployed that are interested in StatelessSipActivity as initial event. Until such service is activated the RA won't do anything. As soon as one such service is deployed, the RA will create an activity for all future SIP events to be fired on. The RA will fire StatelessSipActivity for each newly deployed service that is interested in this event to give the service a chance to attach and begin receiving future SIP events for stateless use.

This aproach is similar to the way we're introducing auto-dialog creation for dialog stateful services.

Thoughts?

Ivelin