First basic version of SIP Outbound support (RFC5626)
Jonas Borjesson
I previously asked a question regarding the support for SIP Outbound
(RFC5626) and since the container currently do not have this support,
I went ahead and implemented a first basic version of it. There are
still more things to do but it works for my scenario and I also wanted
to get some more feedback from the community before implementing the
entire thing (this is the first time I see the code base so it’s easy
to get lost and put the solution in the complete wrong place).
So, the basic use case I want to support is when the container is
acting as a B2BUA (hence, just a UAS from the clients perspective) and
one of the clients is behind a NAT. As you guys know, the client will
claim that it has ip x but the nat:ed address is really x” (bis) so
when we send a subsequent request back to that client, we really
should be sending it to x”.
Before getting into the stuff I added I just want to point out that
RFC5626 mainly talks about proxies and explains quite in detail how a
proxy would deal with this scenario. However, I think it is important
that a UAS actually can support this as well, something the RFC
doesn’t really talk about (unless I just don’t understand it)
Anyway, at a high-level, this is what I did:
In the JAIN SIP stack, there is already support for “connection reuse”
since it will store each incoming connection in an internal table and
file it under a “connection key” (see: TcpMessageProcessor). In a NAT
scenario, the stack will actually ask the socket for the “real”
address and store it under that address. So, in our scenario above,
the incoming connection will be stored under address x”. Hence, if we
just give the stack the right “key” it would in fact find the correct
connection and reuse it and everything would work.
So, digging around I came to the following solution (thank you step debugging!):
* For incoming dialog creating requests, check if the URI that pointed
to us (either the top-most route or the request-uri) has the “ob”
parameter and if so, do:
+ Generate a flow-token (see section 5.2 Generating Flow Tokens in
RFC5626) and store this flow under that key.
+ If we are acting as a proxy, then add a record-router header
containing the flow token and follow the guidelines in RFC5626.
+ else, we are acting as a UAS so just keep track of this stuff
internally (or we could stamp the flow token on the contact uri if we
want to I guess)
* For incoming subsequent requests:
+ essentially the same as for initial requests but just update the
existing flow if the connection info has changed.
* For outgoing subsequent requests:
+ When determining the next hop (SipServletRequestImpl.send()), if
the next uri to resolve has the “ob” parameter, then do:
- if the uri has a flow token stored within it, lookup the
information associated with that flow and set the uri of the next hop
to point to that information.
- if the uri doesn’t have a flow token, then if we are a UAS
then it may be stored internally (unless we of course stamped it in
the contact uri so perhaps that is a better solutions so we don’t need
special code for handling a proxy vs a uas scenario) so look it up and
use that flow.
That is the entire solution and the following classes were changed (of
course, see attached diff):
* InitialRequestDispatcher - this class will be the one checking for
the “ob” parameter in the URI pointing to us and store the current
flow on the SipSession so that it can be accessed later.
* SipServletRequestImpl - when a request is about to be sent out, it
will figure out the next hop to where the request will be sent. It
simply does this by either extracting out the uri from the top-most
route header or the actual remote target (the request-uri, which of
course came from the contact-header in the initial request). However,
we should now examine this “uriToResolve” to see if it has the “ob”
parameter set. If so, see if we can find a “flow” for it and if so,
set the “uriToResolve” to point to this URI instead (which is the URI
that was stored in the InitialRequestDispatcher as described above).
So, that is the entire fix for now. There are still stuff to do (proxy
scenario, dealing with updating the flow for subsequent requests
(looks like the code then probably would go into
SipApplicationDispatcherImpl???) but this takes care of my initial
scenario so for now, I am happy. However, I do want to contribute with
a full solutions if you guys think it would be valuable. The reason
for this is simply:
* Give back to the community
* Get more people to crack down on my solution and therefore increase
the chance of this actually working...
So, a win-win situation I hope...
Anyway, let me know if there is something I should change/do differently/etc.
Thanks,
/Jonas
Jonas Borjesson
I am just wondering if anyone has any comments/suggestions regarding
my proposed initial solution for SIP outbound within the sip
container. The current plan is that I will go live with these changes
but would love to get some feedback from the community...
Thanks,
/Jonas
Vladimir Ralev
I missed your first email. I will take a look in the next few days and
update you. Thanks a lot.
On Fri, Sep 9, 2011 at 9:09 PM, Jonas Borjesson
Jean Deruelle
Sorry but it slipped. Can you update this issue with your patch http://code.google.com/p/mobicents/issues/detail?id=2254 as we intended yo add support for that RFC in MSS 1.7.
Unfortunately I reworked a lot the trunk to make the mss core container independent. If you can't update your patch to trunk, I'll still try to take a look at it next week
Thx !
Jean
Jonas Borjesson
Sure, I will try and get all of that done this weekend (probably
Sunday - note, my timezone is -9 hrs so it may not be available to you
guys until your Monday)
/Jonas
Jonas Borjesson
I ran into some trouble with the latest and greatest. After merging I
couldn't get it to compile so to make sure it wasn't a bad merge I
checked out a completely fresh version of the trunk, wiped out my
local maven repo but still it would fail. The first failure:
Access denied to:
http://repository.jboss.org/maven2/trove/trove/2.1.1/trove-2.1.1.pom
As it turns out, this has been discussed here:
http://seamframework.org/162696.lace so after adding
https://repository.jboss.org/nexus/content/repositories/deprecated/ to
the repositories I got further but then ran into the next missing
artifacts:
Failed to execute goal on project sip-servlets-jboss5: Could not
resolve dependencies for project
org.mobicents.servlet.sip:sip-servlets-jboss5:jar:1.7.0-SNAPSHOT: The
following artifacts could not be resolved:
org.mobicents.cluster:core:jar:1.12-SNAPSHOT,
org.mobicents.cluster:cache:jar:1.12-SNAPSHOT,
org.mobicents.cluster:timers:jar:1.12-SNAPSHOT: Could not find
artifact org.mobicents.cluster:core:jar:1.12-SNAPSHOT in
oddthesis.SNAPSHOT.repo (http://repo.oddthesis.org/maven2/SNAPSHOTS)
Since I already had the offending jar's in my old installation I was
hoping things would work anyway (by commenting out this module in the
pom I could build it all) but after copying over the new jar's to my
install is blew up on many ClassNotFoundException so I guess either my
manual patching isn't working or I really do need the new versions of
everything.
Does anyone have an idea what I am doing wrong?
Thanks,
/Jonas
Jean Deruelle
Jonas Borjesson
Your updates to the pom and the move of SipStandardManager.java to the
correct location fixed it. Note, I still had to update the root pom to
use the jboss repository of: http://repository.jboss.org instead of
http://repository.jboss.org/maven2.
I attached the diffs to the actual issue here:
http://code.google.com/p/mobicents/issues/detail?id=2254
Let me know if there are anything else I can do.
Thanks,
/Jonas
Jonas Borjesson
I am just wondering if you need anything else from me in regards to my
proposed fix for the sip outbound stuff?
Thanks,
/Jonas
On Mon, Sep 12, 2011 at 10:26 PM, Jonas Borjesson