Skip to main content

3pcc example doesn't work with sip proxy

4 replies [Last post]
thedax
Offline
Joined: 2006-10-27

Hello everyone,
I'm moving my first steps with Mobicents and I'm encountering some problems to make things work, so I'm posting here, hoping that someone can help me.

I downloaded the "mobicents-examples" project from the CVS in orded to try out some working services before starting to implement new ones.

I'm currently trying out the Third Party Call Control example. These are the machines involved:

- MOBI: a PC running the latest "mobicents" project from the CVS, on top of JBoss 3.2.8SP1
- SERPROXY: a PC running openser 1.1.0 which plays as SIP Proxy and SIP Registrar for my users
- UA3 & UA4: two PCs running the X-Lite 2.0 client, registered on SERPROXY as "user3" and "user4"

To trigger the TPCC service running on Mobicents I'm using the JMX MBean called "click2dial" which is included in the project.

The first thing I tried to do was a _direct_ call to the UAs, i.e. using SERPROXY only for registration. In other words, I invoked the makeCall operation of the click2dial MBean with the following parameters:

p1 = "sip:user3@UA3"
p2 = "sip:user4@UA4"

Where "UA3" and "UA4" are the IP addresses of the stations running the UAs. This configurations works nicely: the callee (UA4) rings, I accept the call, the caller (UA3) rings, I accept this too, and at this point the SIP session is gracefully established and the UAs can talk to each other.

The next thing I tried to do was closer to a real-life scenario, i.e. establishing a call between users whose address is unknown, so they must be identified with the correct "domain", which for me is the SERPROXY ip address. So I invoked the makeCall operation of the click2dial MBean with these parameters:

p1 = "sip:user3@SERPROXY"
p2 = "sip:user4@SERPROXY"

This invocation makes the callee (UA4) ring as before, but when I accept the call, nothing happens on the caller side (UA3), which means it never gets invited by MOBI. I looked at the Mobicents/JBoss console, and this is what I found:

17:17:27,718 INFO [SipResourceAdaptor] Resource adaptor delivering event:/n 28
z9hG4bK50da277818007efb46c726f8bda318f0
17:17:27,750 WARN [CallControlSbb] Received 200 response from forked dialog
17:17:28,062 INFO [SipResourceAdaptor] processTransactionTerminatedEvent() gov.nist.javax.sip.stack.SIPClientTransaction@1549159f
17:17:34,437 INFO [SleeContainerLingeringServiceSbbRemoverTask] == REMOVAL START:ServiceID[JAIN SIP Proxy Service#NIST#1.0] ==
17:17:34,437 INFO [SleeContainerLingeringServiceSbbRemoverTask] STARTING REMOVAL
17:17:34,437 INFO [SleeContainerLingeringServiceSbbRemoverTask] REMOVING SBBE[0104d2caa8d66cfd:-19074bf3:10faaf1e3b6:-7ff1]
17:17:34,437 INFO [SleeContainerLingeringServiceSbbRemoverTask] == REMOVAL COMPLETED COMPLETED:ServiceID[JAIN SIP Proxy Service#NIST#1.0] ==

Which leads me to think that something is wrong with the last "200 OK" SIP message, sent by the callee UA4 when the call is accepted. This message appears on the log, which makes me think SERPROXY forwards it to MOBI, but for some reason Mobicents doesn't think the message is fine and kills the transaction.

I checked the source code, and found that the WARN message output and the call termination happens inside the classes "BeforeCalleeConfirmedState" and "AfterCalleeConfirmedAndBeforeCallerConfirmedState" in the methods called "handleOK". The two classes are internal to the CallControlSbb class. This is the code that prints the message, it is the same for the two classes:

// Check that the dialog of the event is the same as in the session
// If not this is the result of a fork, we don't handle this
try {
Dialog eventDialog = sipUtils.getDialog(event);
Dialog currentDialog = getDialog(eventDialog.getCallId().getCallId());
if ( !eventDialog.equals(currentDialog) ) {
log.warn("Received 200 response from forked dialog");
return; // We don't currently handle this. Should send ACK and BYE
}
} catch ( SipException e ) {
// TODO Handle this
}

So I guess that there are two different dialogs involved, and the situation isn't handled by the CallControlSbb. Is there a way to fix this and make the example work with a proxy too?

Any help or suggestion is welcome.

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
baranowb
Offline
Joined: 2006-01-09

17:17:34,437 INFO [SleeContainerLingeringServiceSbbRemoverTask] == REMOVAL START:ServiceID[JAIN SIP Proxy Service#NIST#1.0] ==
17:17:34,437 INFO [SleeContainerLingeringServiceSbbRemoverTask] STARTING REMOVAL
17:17:34,437 INFO [SleeContainerLingeringServiceSbbRemoverTask] REMOVING SBBE[0104d2caa8d66cfd:-19074bf3:10faaf1e3b6:-7ff1]
17:17:34,437 INFO [SleeContainerLingeringServiceSbbRemoverTask] == REMOVAL COMPLETED COMPLETED:ServiceID[JAIN SIP Proxy Service#NIST#1.0] ==

This is delayed removal of SbbEntities for service - it allows services to end gracefuly.

look through conf of sipra and check if auto dialog support is turned of. Im not sure if jain sip libs are up to date, and I doubt but it could happen that support is already present - this could explain doubled dialog.

ivelin
Offline
Joined: 2003-07-13

we will include the sip ra, proxy and registrar with the example to make it more straightforward to try.

thedax
Offline
Joined: 2006-10-27

> we will include the sip ra, proxy and registrar with
> the example to make it more straightforward to try.

Thanks, that would be really nice to start with.

In the long run, however, I'd still like to be able to use external proxy & registrar, like I'm trying to do now.

I'm saying that because in the currently available revision of the example (CVS), some variables, addresses, etc. are hardcoded, so that even the deployment can be difficult on some setups.

If possible, I would like to contribute to the development of this example. Is there someone currently working on it? If newer revisions of the used modules (i.e. sipra) exist somewhere, I would like to try to integrate them into the code and make things work in a general context (non-local proxy & registrar), making the configuration less code-dependent.

ivelin
Offline
Joined: 2003-07-13

thedax, you are welcome to begin playing with the code and make improvements. Please submit patches to bugzilla for review.

Bartek (baranowb) will make the necessary changes to include the proxy&registrar in the example so its easier to try. He will also work on stabilizing the new SIP RA, proxy and registrar.

Your first area of focus could be decoupling the hardcoded dependency of the example to the default proxy&registrar.

Ivelin