Skip to main content

SIP Services - 16.5 Determining Request Targets

1 reply [Last post]
ivelin
Offline
Joined: 2003-07-13

> 16.5 Finding new targets
> * If we have more than one target the message is
> forked, here we have to create "Response context" -
> meaning we need something that will have trace of
> all
> CTx associated with original STx that was created by
> original request. Using InitialEventSelector that
> sets custom name as call-Id (and possibly plus From
> tag value?)

what difference will it make whether the From tag value is part of the convergence name?

> as good idea - CTxs and STx can have that in common,
> right? This way we will have one proxysbb entity to
> handle forward.

Don't have enough experience with forking apps to tell, but intuitively seems like one point of control for forked branches of the same dialog makes sense.

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

> > 16.5 Finding new targets
> > * If we have more than one target the message is
> > forked, here we have to create "Response context"
> -
> > meaning we need something that will have trace of
> > all
> > CTx associated with original STx that was created
> by
> > original request. Using InitialEventSelector that
> > sets custom name as call-Id (and possibly plus
> From
> > tag value?)

Call forking is a mess to handle in a proxy server. There is a pointer Transaction.applicationData that is meant explicitly for response context tracking.

>
> what difference will it make whether the From tag
> value is part of the convergence name?
>
> > as good idea - CTxs and STx can have that in
> common,
> > right? This way we will have one proxysbb entity
> to
> > handle forward.
>
> Don't have enough experience with forking apps to
> tell, but intuitively seems like one point of control
> for forked branches of the same dialog makes sense.