[SR-Users] SIP REFER support...

[Jignesh Gandhi]

Thanks you very much for you suggestion.
I really do need to generate RE-Invites upon receiving REFER . I don't want to pass the REFER
along to the switch. I understand that OpenSER can't do this.

 I have looked at OpenSIPS and  may be it can generate re-invites with B2BUA scenario....

Can you suggest any thing else, besides getting an HP or Tekelec SIP AS and spending
a lot of money for a specific functionality.

thanks for you patience..

--Jignesh 

________________________________________
From: Henning Westerholt [henning.westerholt at 1und1.de]
Sent: Tuesday, May 11, 2010 8:39 AM
To: sr-users at lists.sip-router.org
Cc: Jignesh Gandhi; Iñaki Baz Castillo; users at lists.kamailio.org
Subject: Re: [SR-Users] SIP REFER support...

On Tuesday 11 May 2010, Jignesh Gandhi wrote:
> UA-2 calls UA-1 and a call is established..
> UA-1 puts UA-2 on hold and calls out to UA-3,
> Once UA-3 anwers , UA-1 puts that call on  hold as well.
> At this point , UA-1 sends  A REFER to OpenSER, to refer UA-2 to UA-3.
> Basically before connecting the UA-2 to UA-3, UA-1 wants to get out of the
> call path and have UA-2 and UA-3 talk to each other directly.( basically a
> consultative call xfer ). So OpenSER will have to do 2 Re-Invites and also
> respond back to UA-1 with NOTIFY and status of the RE-Invites( one with
> SDP and one without ).
>
> I understand that I would have to write a custom module or callflow to
> handle this , but is there anything in OpenSER that would not support this?

Hi Jignesh,

if you route the REFER as normal in-dialog requests as discussed you don't
need to write a custom module for this. This routing is usually done in a
"loose_route" statement, you probably should already have something like this
in your cfg.

If you want to route it differently you can also do it by pure configuration
means, you could for example check with the pseudo-variable $rm for the
message method string and then just forward it as you like.

Cheers,

Henning