CouchBase/CouchDB is probably the easiest and most available one out there. It's particularly well suited for app backends too, as both the backend and mobile apps can talk to the same database, in theory eliminating the need for the backend to handle data syncing.
Those are good reasons, and it's also true that CouchDB will use a lot less resource overhead than a full-bore RDBMS under load. Depending on the use case, it might also prove decidedly easier to scale.
But the place where NoSQL really shines is storing amorphous or heterogeneous data. Because you have no constraints about what goes into a given record, you can record more or less name/value pairs at your whim. As with Perl, though, freedom comes at the cost of potential disorder.
But honestly, with the tiny amount of detail provided, it seems like it's really six of one and half a dozen of the other. If it's just call data being recorded, and the same call data every time, it won't make a huge difference if you use a full-blown RDBMS or a NoSQL database. Either one has its costs (individual PUTs and POSTs in CouchDB for example, can be expensive, whereas queuing and write contention might cause headaches at extreme scales in PostGres or Oracle).
Both an RDBMS and a NoSQL database will deal with replication fairly well, though my personal inclination is to prefer the simplicity of replication in CouchDB right up until the noise level gets out of hand.