Hi Mike,
> I'm not sure I understand the above scenario. Can you include a sip
> ladder diagram and/or an ethereal capture to better describe the rejected
> INVITE.
About the rejected INVITE: we are using a single sipXtapi stack for multiple
simultaneous user agents. Think of it as a PC with multiple audio cards each
serving one user.
Now the users can dial out, and can be reached from the outside. Fine, no
problem. However, now these users want to call each other, and that's where
things go wrong.
Staying with the PC scenario we have [EMAIL PROTECTED] and
[EMAIL PROTECTED] and Ann wants to call Bob.
This fails because somewhere in SipConnection.cpp (where it says: "Special
case: We sent the invite to our self") sipXtapi refuses to make a connection
with itself. Removing this check (just for the heck) results in other
errors, probably because the sipXtapi stack is uncomfortable with handling a
call that is both incoming and outgoing at the same time.
Note that mypc is not really a PC but rather a 50MHz piece of embedded
hardware serving multiple (up to 4) users.
We were thinking about - but have not tried yet - to use two instances of
the sipXtapi library: one for incoming and one for outgoing calls, but we
were hoping that a less complex (less heavy in terms of memory usage and
number of threads) solution would be possible.
Herman
-----------------------------------------------------------------
Herman Kuiper - m: [EMAIL PROTECTED] - w: http://www.frontier.nl
Beech Ave 162 - 1119 PS Schiphol-Rijk - t/f: 020-6589034/6142816
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
