Q:

SSH invocation of a subsystem SFTP using command line

I am facing a problem where I have an SFTP server (with no SSH shell access).  
When from a client machine I do SFTP request it works:
sftp username@remote_IP

Then if I do a SSH request it hangs
ssh -l username -s remote_IP sftp

But the ssh man page suggest that
-s      May be used to request invocation of a subsystem on the remote
        system.  Subsystems facilitate the use of SSH as a secure
        transport for other applications (e.g. sftp(1)).  The subsystem
        is specified as the remote command.

Does SSH server at remote server must enable this or there is some other way out for this?  
Adding verbose logs .... let me first share you the sftp verbose mode logs which suggests: 
debug1: Authentication succeeded (publickey)
debug1: fd 5 setting O_NONBLOCK
debug2: fd 6 is O_NONBLOCK
debug2: TCP receive buffer size: 49640 B
debug1: SSH receive window size: 198560 B
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: ssh_session2_setup: id 0
debug1: Sending subsystem: sftp
debug1: channel request 0: subsystem
debug2: callback done
debug1: channel 0: open confirm rwindow 2097152 rmax 32768
debug2: Remote version: 3
debug3: Sent message fd 5 T:16 I:1
debug3: SSH_FXP_REALPATH . -> /root
sftp> pwd

Now I am showing the verbose output of ssh -l username -s remote_IP sftp
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug2: fd 4 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 2097152 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: subsystem request accepted on channel 0

This is where it hangs. 
The problem in short is "If SFTP works and is enabled on server what happens to ssh which is calling subsystem sftp on remote server"? What exactly is required at server end or as a matter of fact at client side to make it work?
Please clarify my basic understanding, if I have understood something wrong.  

A:

What do you expect it to do?
It starts the SFTP server. And the server waits for SFTP requests, particularly for the SSH_FXP_INIT. And it never gets one. The SSH terminal (ssh) will hardly send an SFTP packet.
So it hangs. As expected.

(Note that despite the same, the SSH_FXP_INIT is an SFTP request, not an SSH request. The SSH_FXP stands for something like "SSH file exchange protocol")

You haven't really explained us what do you expect. 
So let me guess.
You actually believe that the SFTP is a textual protocol. That the commands (like rm, put, etc) that you type in the sftp (OpenSSH command-line SFTP client) are real commands that go to the server. They are not. The SFTP is a binary protocol. Those commands are proprietary commands of one specific SFTP client implementation. The client (OpenSSH sftp) translates those textual commands to binary SFTP packets/requests and sends them to the server. And then it translates the binary responses from the SFTP server to human readable textual messages.
Those textual commands cannot be real exchange with the server even theoretically. Simple commands, like the rm, could. But what about the put or get? If you do put /local/path, how can the SFTP server access the local file to read it? It cannot. The SFTP client does that.
That's similar to FTP. The FTP is a textual protocol. You can theoretically talk to the FTP server by typing the commands. You can delete remote files this way for example (using DELE /path/to/file command). But you cannot upload or download files this way. That requires cooperation with the local FTP software.

What exactly is required at server end or as a matter of fact at client side to make it work? 

Your server-end works as expected. But you need an actual SFTP client on the client side. 

