[Users] Differentiate INVITEs

[Jerome Martin]

Kristian,

Just a quick note : if you need to differentiate an initial INVITE from
a re-INVITE, I would say the most RFC-compliant way would be to check
for a to: tag. If there is one, then this is a re-INVITE. If not, then
it's an initial invite.

Based on that information, you can route either invites wherever you
please, but keep in mind that after the first re-INVITE, the phone will
send a second one to restore the initial media session, and that one
needs to be handled carefully. The initial outbound gateway won't mind
if there is a jump in CSeq between two transactions (that's in RFC3261),
but still, depending on wether the phone keeps the same ports as in the
initial media session or not, you might need to to more or less hacking
in order to restor the initial session when MOH ends.

I've never used client-side MOH, and this seems pretty complicated in
terms of handling.

Cheers,
Jerome

On Thu, 2007-05-10 at 14:30 -0400, Kristian Kielhofner wrote:
> On 5/10/07, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> > Hi!
> >
> > You cant do MOH in openser. MOH is an endpoint feature. Some phones
> > allow to configure a MOH URI (SNOM) which I guess is used for reINVITEs.
> >
> > Maybe you can implement it with sems - catch the on-hold reINVITE and
> > "tell" sems to stream RTP to the other party - ask the sems guys.
> >
> > regards
> > klaus
> >
> 
> klaus,
> 
>  Thanks for the reply.  I'm not looking to do anything too special in
> openser.  If anything, all I need to do is add a check for the address
> in the SDP for an INVITE.
> 
>  Some phones do allow you to configure a MOH URL but not all do.  I'd
> like to come up with something that will work for me and other people
> in the community on any phone.  Plain 'ol generic SIP is probably the
> only way (this is how Asterisk does it so seamlessly).
> 
>  If I implement this with SEMS I will have the same problem.  As you
> said, I still need to "catch" the on-hold re-INVITE from the phone and
> send it to SEMS.  I already have Asterisk servers (and I'm much more
> familiar with Asterisk than SEMS), I might as well try to send the
> intercepted (for lack of a better term) re-INVITE to Asterisk (and
> have Asterisk process it as a normal call) - not to SEMS (although it
> would probably also work for SEMS in place of Asterisk).
> 
>   It looks like textops might be able to do this in a hack-ish sort of
> way...  I'll try it and see what happens but I would certainly like
> something cleaner.
> 
>  What would need to be added to OpenSER to support checking for this?
>  Even exposing a few of the values (perhaps as pseudo-variables) from
> the SDP on an INVITE would be a great start.  I'm sure that this is
> more of a dev list question but I thought that I would ask here
> first...
> 
> Thanks again for the reply!
>